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. Calvin
