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.


Reply via email to