On Fri, 12 Nov 2004 11:34:35 +0100, Daniel Egger <[EMAIL PROTECTED]> wrote:

> It would be really cool if the pixel data addressing was pluggable so
> one could easily write a different storage backend. On top of my head
> there would be several schemes I'd like to try:
> - A simple linear memory segment with COW for new layers
> - dito but with RLE compression (and thus more complex addressing)
> - Line based addressing with COW and aliasing for duplicate lines,
>    with LUT for each line
> - Planar memory segments (Shoot now! ;))
> I don't know what GEGL will buy us exactly because we certainly
> need a change from "store those 32bit RGBA values" to something
> more variable but IIRC GEGL is only about pixel composition, not
> storage.

GEGL is about image compositing, not pixel compositing, thus it has to
deal with efficient memory representations as well. In my view of how
things will be after a full integration, gimp uses GEGL for all it's
image processing needs, even the paint tools will most likely be
reimplemented to use GEGL.

The largest problem with making the image representation pluggable is
that it either complicates op (short for image operation, plug-ins in
GEGL) development or adds overhead due to additional copying of values
needed to provide a simple interface.

Layers (or their equivalents after GEGL integration) can theoretically
be unbounded  surfaces instead of square,. there are various ways to 
such sparse allocation of images, and IIRC the tile based caching
system Dan implemented in gegl/gegl/image would allow this.

After integration of GEGL various other speedups can be achived, by
for instance caching static portions of the compositing graph, other
optimizations and rearrangements are also possible on the graph level.


Software patents hinder progress | http://swpat.ffii.org/ 
Web :  http://pippin.gimp.org/ <- that's where my GEGL like playground is hidden
Gimp-developer mailing list

Reply via email to