On Tue, Nov 09, 1999 at 01:27:29AM +0100, Ewald R. de Wit wrote: > Anyway, today I went over the Gimp sources and noticed how complicated > the tile architecture makes things and I couldn't help wondering why > the heck it was put in. All it seems to do is to give you an order of > magnitude slower speed when dealing with large images. And large > images were supposed to be the very reason for a tiling architecture. I have no idea where this came from, Ewald did you actually do any benchmarking, or just a few thought experiments? Computers do not behave in practise as it may seem they should ideally. Here are some practical results from my real Gimp machine, a PII 300MHz with 64Mb of memory and ~64Mb of swap. This is with CVS Gimp. If I configure Gimp to believe that it has as much memory as one might conceivably need, then the results are as follows: Loading a large image (*): Wait 10 mins, get bored, try to kill, but the machine is in a swap death loop, after 5 more minutes, just as I log in as root from a serial console, X experiences resource starvations and so Gimp, Gnome, xterms and everything go into the drink. If I configure Gimp with a large but not improbable tile cache (64Mb): Loading a large image (*): Wait 5 mins, TIFF loader finishes, after a further 10 mins the image has been drawn at 10:1 reduction. Now with the defaults as supplied (12Mb ISTR): Loading a large image (*): Wait about 2 mins, loader finishes and now after a further 2 or 3 mins the image has been drawn. And finally with my preferred settings (20Mb): Loading a large image (*): Wait about 2 mins, loader finishes and now after a further couple of minutes the image is drawn, however later performance is slightly faster than in the default case above. (*) A large image here is one which genuinely WILL NOT fit in memory, by any stretch of the imagination. It is a JPEG tiled TIFF (nasty!) of dimensions 7274x9985 and in full 24-bit colour. Nick.
