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

We have our display,. no data loaded



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.



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
|    |
|  scale
|    |
|  crop
|    |


when we want to do color correction operation it is inserted between
the image_data and the display.



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.


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)


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.


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/
Gimp-developer mailing list

Reply via email to