On Thursday 11 November 2004 20:41, Sven Neumann wrote:
> Hi,
> Dov Kruger <[EMAIL PROTECTED]> writes:
> > I noticed that gimp is very slow for large images compared with
> > Photoshop. We were recently processing some 500Mb images, and on
> > a fast machine with 2Gb, gimp is crawling along, while on a
> > slower machine with only 512 Mb, photoshop is considerably
> > faster.  I attributed it to a massive amount of work in
> > photoshop, using sse instructions, etc. but then noticed that the
> > default viewer in redhat allows me to load images far faster even
> > than adobe, and zoom in and out with the mouse wheel in realtime.
> >
> > Granted, because you are editing the image, not just displaying
> > it, there has to be some slowdown, but I wondered if there is any
> > way I can tweak gimp, do I somehow have it massively
> > de-optimized. When I first set up gimp-2.0, I tried both 128 and
> > 512 Mb tile cache sizes. 512 seems to work a lot better, but it's
> > still pretty bad. Any idea as to the area of the speed advantage
> > of Adobe?
> If you are processing large images and have 2GB available, why do
> you cripple GIMP by limiting it to only 512 MB of tile cache size?

The point here is no news for us. 
The GIMP is not as fast as it can possibly be one day for large 

I've put some thought on it these days - (just thinking, no code), and 
one idea that came by. What I intend with writing this is that 
everybody have it in mind when making the transition to GEGL - when 
it  will be a favorable time to implement it:

All images in the GIMP could be represented twice internaly - on e 
with the real image representation, and a second layer stack 
representing just what is being seeing on the screen. All work that 
should "feel" realtime-like should be done first on the screen 
representation, and them processed in background, on the actual layer 

This would allow, overall, a faster use of the tools, including the 
paint and color correction ones.
It could also clean-up some situations like the JPEG save preview 
layer, and the darkening seen in teh current crop tool - as these 
things would not be in the "real" image data, just on the display 

In GEGL terms, that means two graphs for every image.
Of course none of this is imediate, and I am thinking on a discussion 
that should mature from now to, say, some 3 or 4 months, if GEGL will 
be put in the next release.

While there may be a first impression that this would take up more 
memory and resources than having a single representation of the 
image, I'd like to put in consideration thde following numbers:
A typical photo I open up for viewing/correcting is 2048x1576 (My 
camera's resolution). That would take up, in raw memory, no undo 
tiles considered, more than 9 Megabytes for a single layer. Each of 
which bytes should be "crunched" each time I make a small adjust on 
the curves tool. 

On the other hand, I view this same image on a window that is about 
800x600 -> 1.5MB in size. 

Of course  that care must be taken for that this doesn't slow 
everything down when 

I know this is no news, it is hard to do, and all that. But it is 
nonetheless a model that we have to keep in mind, for, at this point, 
it seems no less important that implementing tiles had been some day.

Ok, I may  also  have got it all backwards, and there may be a way of 
optimizing the current model without two image graphs at all.  :-) 
But it still a discussion that should be mature in a foreseable 

> Sven


Gimp-developer mailing list

Reply via email to