-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Calvin Williamson wrote: | 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. Yes, but there is no reason not to have an image type that one doesn't need a node to use. In which case, node-result images and in memory images have very different requirements. Consider: 1. Images should never, never interect with a cache if they are the result of an op, because the op is a much better place to cache the results of the op (since several images may be using the same result tiles at different times). 2. An op result image needs to communicate with the op while tiles are being fetched from the image, to ensure that only the tiles that the image absolutly needs are generated for the op. | 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). That is not efficient. A gegl op should be able to cache to results of at least a few of its tiles (if not lots more, should be configurable), since if an image was requested once from the pipeline, it is likely to be requested again. | 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. In order to have truly on demand tile-processing, there is no other way. ~ Requesting tiles from a result image is the most efficient way of demanding tiles at a particular time. There are a couple problems with simply generating the entire image and storing the results all at once. 1. Since we are only able to specify rectangular DOD's and ROI's it is more than possible that the entire region of the image will not be needed. Thus it is more efficient to wait until the tile is demanded. 2. Since a single output of an op may be used, both more than once, and at different times (consider if the same input is connect to a later point in the graph), keeping the results in the op to be fetched by the images (instead of being fetched from a cache, a very similar process, btw) it the only way a cache makes sense. 3. Waiting until the tile is absolutly demanded also makes it easier to keep track of multithreaded tile processing, since if a tile is being requested, its requirements will be recursivly filled and the tile can be put on the queue near it's prerequisites. (if you just put entire regions all at once, this, obviously is not true). | 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. No, I think I meant what I said. GimpImage is a stack of GimpLayers, conceptually, and a GimpLayer is a combition of a GimpDrawable and some associated blending info. For all the reasons above, nothing should keep around a GeglImage unless it is actually processing that region (as this locks up some resources). Thus, GimpImage maps to a tree of ops. GimpLayer maps to a blend op and a leaf op. A GimpDrawable maps to a leaf node, which probably just contains a bunch of tiles (a la' a gegl-buffered-image, but with all the op stuff connected to it). | 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. Why do you think that? | 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". A tile manager is totally unsuited to being passed through the ops in an efficient way, for the reasons above. | Then in a subsequent pass replaces TileManager by a new GeglImage. For all these reasons is the reason I am proposing do it the other way around. - -- Dan -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFABWraad4P1+ZAZk0RAlfoAJ90tOHIVlL3C5zISJgaU2b2YW4p4ACfWdXr a7FOsg9IeMJ1BeqBTm2oU0o= =Akte -----END PGP SIGNATURE-----
