Re: [Gimp-developer] a GEGL integration strategy

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, 7 Mar 2005 22:55:26 +0100 (MET), Robert Ögren <gtk@xxxxxxxxxxx> wrote:
> Hi everybody,
> On Tue, 14 Dec 2004, Øyvind Kolås wrote:
> 
> > The suggestion of starting the integration process of GEGL into gimp
> > with the paint tools came up on irc today.
> >
> > I have put some thought into the order such a conversion might happen in,
> >
> >   blend
> >   pencil
> ...
> > The order lists what I think is increasing level of complexity in usage
> > of gegl for the tasks, such a multipurpose gegl tool can probably be
> > implemented and coexist with the rest of the tools while the migration
> > happens.
> 
> Please forgive me if this question is too basic, but I don't understand in
> which way the paint tools are going to be implemented as GEGL ops.  Will
> each stroke be a separate node in the graph, or will several strokes
> be accumulated into one node? Or am I completely misunderstanding things
> here? What will the graph look like after a stroke with the pencil tool?

This depends on the implementation of drawables, drawables are nodes
within the graph that provide an image buffer. The simplest approach
is that this node is
backed by an in memory buffer/set of tiles. With such an approach the
paint tools would replace this backing image data, by filtering it
through stroke operations.

> What happens when you save an image into xcf2 (or whatever it will be)? Is
> there a point where parts of the graph are flattened, or will all
> manipulations that have ever been done to the image be replayed when the
> image is loaded again?

Such a procedural "cache" of operations is useful for more things than
an infinite undo history, small file size etc. It also means it would
be possible to resize an image after interactive operations.

For the GEGL ops themselves it shouldn't matter if they are used in
one mode, or the other. Initially the simplest mode, by mangling tiles
directly will probably be implemented since the integration would
deviate the least from current code base.

> (I have looked through the GEGL API docs and the GGGL pages so I think I
> understand the graph and operation stuff, it's the integration with GIMP
> I'm interested to hear more about.)

After discussions it has been found more probable that integration
should start with the display filters, and color management.

/Øyvind K.

-- 
Software patents hinder progress | http://swpat.ffii.org/ 
Web :  http://pippin.gimp.org/

[Index of Archives]     [Video For Linux]     [Photo]     [Yosemite News]     [gtk]     [GIMP for Windows]     [KDE]     [GEGL]     [Gimp's Home]     [Gimp on GUI]     [Gimp on Windows]     [Steve's Art]

  Powered by Linux