On Sun, 14 Nov 2004 23:08:08 -0200, Joao S. O. Bueno Calligaris > 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. I think this all belongs within GEGL, these are actually optimizations that can happen within GEGL, gimp should just request what it wants and GEGL should magically do the right thing. Reasoning and explaination of magic follows,. I will be using layer stack / compositing graph interchangeably in this mail, since the layer stack / drawable tree will just be an abstraction layer above a graph. We have our display,. no data loaded Display ---------------------------- Then we load an image, either it is memory mapped from disk, or it is in memory or it is decoded from png each time,. there is no need to care about it. Display | Image_data --------------------------- How is the image_data displayed?, we might have a zoomed out version, that is clipped by the image window we can imagine the Display not to have two implied nodes that crops and scales the image .-[Display]--. | display | | | scale | | | crop | | `---------- | Image_data ----------------------------------- when we want to do color correction operation it is inserted between the image_data and the display. display | color_correct | image_data ------------------------------------- thinking about it directly we would assume that all the pixels in the image have to be color corrected with this scheme,. but the graph presented here can be flattened (extending the implied nodes within display) and reordered without it affecting the final composited image. display | color_correct | scale | crop | image_data scale and crop are both affine operations, all affine operations should, if possible, be collapsed and move towards the image data sources of a graph (at this point layers and all higher level gimp data structures don't matter it's just a large graph of operations to be processed) display | color_correct | affine | image_data when doing changes to color_correct's parameters only, GEGL should be able, if it has enough cache memory available, to cache the image data resulting from the affine transform, thus only the changing part of the graph needs to be recomputed. The point where such reorganizations become harder is for ops like blur, which depend on the spatial resolution of the data coming in, this essentially means that a "rewriting" pass of the graph needs to change the blur radius etc, some operations are not possible to reorganize like this. The problems I outline would also happen for the dual processing graph approach, and the same meta data would be needed about the ops involved. Thus what I present here is actually just saying that this optimization can happen later within GEGL without changing how gimp uses it. /pippin PS: please excuse the lousy ASCII diagrams, gmail uses a non proportional font and thus make it difficult. -- Software patents hinder progress | http://swpat.ffii.org/ Web : http://pippin.gimp.org/
