Requests which are larger than a file tile require processing at the server to compose them into whole images, but in practice this is so fast as to be unnoticeable. However large tiles mean scrolling has long infrequent delays rather than short frequent delays. Time to repaint a 1500x1500 screen in seconds vs request image size, for server processing and mainly client processing colour. The graph in figure 3 shows the effect of requesting various sizes of image from the server. The area repainted is equivalent to around 9 normal screens so that the times were more easily measured.
Larger requests seem to have lower overheads and hence faster repaints.
The line for cached is where the server probably has the tiles in cache already, so it does little processing. The blue lines are for colour processing on the java client and show that requesting the file's tile size of 128 is very efficient and that java processing leads to little slow-down. With low bandwidth or busy network connections the bottleneck is clear and the time spent computing in the browser becomes less important. Tests were carried out with images being read from a 12X CD drive on an SGI Origin 200. This provided fast browsing and file system caching helped keep response times low for multiple clients.