On Thursday 11 November 2004 20:41, Sven Neumann wrote: > Hi, > > Dov Kruger <dkruger@xxxxxxxxxxx> 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 images. 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 stack. 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 shadow. 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 future. > Sven Regards, Joao
