Re: [Gegl-developer] Path to the GIMP

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

On 11/01/04, Daniel Rogers wrote:
> 1. Eliminating TileManager and GimpDrawable and replacing it with
> GeglBufferedImage.  (GeglBufferedImage will be the name of the concrete
> GeglImage subclass that just stores its Tiles in a GeglBuffer (as
> opposed to fetching them from an op)).  GimpDrawable is the thing
> closest in concept to a GeglImage, atm.

I dont know if I understand this correctly. GeglImage (I thought)
was supposed to be our version of image data that passes through
a graph of gegl nodes, being passed along the input and output
properties of the nodes. As such an gegl op may create a GeglImage
to store its output, or alternatively may operate on GeglImages
that are passed to it (either directly through a regular 
gobject style properties or from the output properties of another 
op). But a GeglImage never needs to fetch tiles from an op
in any way. It is the other way around. The op uses the GeglImage
to get tiles and data to write to. Im not seeing GeglImage as 
a client of the Op I guess. I see GeglImage as closest to TileManagers
in gimp right now and that I think is the replacement we should aim 
for. GimpDrawable (and GimpItem and GimpViewable) all currently have 
things like preview caches and parasites, and pointers back to
an owner GimpImage and are at a little higher level on the 
"what is an image" food chain. 

> 3. Modifing GimpImage to GeglImage.  Currently, GimpImage is more akin
> to a stack of GeglImages.  This change shouldn't be too hard (at first),
> from what I can tell.  Mostly, the stuff that changes will be the things
> that use a GimpImage to get the TileManagers and GimpDrawables, and
> those will need to change to to acomodate (1) anyway.  Anywhoo, the
> GimpImage, at this point, will do same thing, just keep a few pieces of
> data in a difference place.

I think you mean GimpImage will use GeglImages (formerly TileManagers),
but might now have a graph of ops instead of an implied stack
the way they do now. GimpDrawables will also be using GeglImages now 
instead of TileManagers too. Specifically I think that all code that 
passes around PixelRegions and TileManagers will be replaced by
a combination of passing around GeglImages and setting 
properties on GeglOps that operate on these images. So I think that
PixelRegions will dissappear as a needed struct.    

I think most of the work in bringing in a new image type is 
related to replacing TileManagers and PixelRegions code all over 
gimp to use GeglImages and GeglOps instead.

That is why I was talking about doing a pass first that does not
use a new GeglImage type but just goes through and refactors the 
"tile manager + pixel regions" into "tile manager + ops".

Then in a subsequent pass replaces TileManager by a new GeglImage. 


[Video For Linux]     [Photo]     [Yosemite News]    [Yosemite Photos]    [gtk]     [GIMP Users]     [KDE]     [Scanner]     [Gimp's Home]     [Gimp on Windows]     [Steve's Art]     [Webcams]