On 12/01/04, Daniel Rogers wrote:
> |
> | There are a couple of ways we could go. One is to wait for
> | all of gegl image dependent classes to get finished and worked
> | out (including new versions of color model, sample model, tiles,
> | caches, etc, etc). This is what Daniel is working on now, and has made
> | some good progress on so far.
> |
> | But there is another way we could do things that would work
> | as well and give us a more gradual way of introducing gegl
> | without trying to replace everything in gimp image processing
> | engine at the beginning.
>
> I don't think this is a good plan. While it would certainly work, it
> also requires adapting all the gegl data types, or the gimp data types,
> or both in order to shove gimp data though gegl data types. Further,
> adding gegl trees first, doesn't get us much. We get: more efficient
> processing (a speed boost, maybe), and the potential to add layer groups
> without too much trouble. To get layer effects (from plugin's anyway)
> requires a redesign of the plugins to support more presistent usage
> (e.g. make them behave like a gegl op, at least on some level). Then,
> we we go to add everything else, we need to discard all of our adaptor
> classes, then introduce GeglImage, then rewrite all the plugins again.
> Now, I don't have a problem with this, except I think introducing
> GeglImage first gets us the most features quickly and makes the harder
> stuff a little faster, in terms of programmer time (because we don't
> make adaptor classes we need to discard later).
>
I know. I hear you. The gradual way is not as pretty. And it means
you have to evolve your set of ops from "gimp-centric" (ie using
combine_regions, and all the other gimp regions calls) to more
"gegl-centric" which basically means that things like the gimp
mega-node combine_regions would get broken into smaller
node pieces (an Add, Mult, Dissolve node etc, etc)
But Im not advocating re-writing any gimp plugins to use this first
set of ops. Plugins continue to ask gimp to do everything and continue
to request GimpPixelRegions and GimpTiles (the plugin versions
of these) from gimp. But everywhere internally in gimp we transition to
ops and tilemanagers (and remove pixel regions from the gimp core
code - of course they still exist inside the gimp ops cause these are just
covers to the gimps blah_region calls, and those are still iterating
over pixel regions). Then we evolve the ops to a reasonable set we want
to expose to the world as part of gegl.
At this point you then fix any 8bit assumptions you have in higher
level gimp code and introduce whatever GeglColorModel, GeglColorSpace, and
GeglColor objects that gimp will wind up using. At this point you
are only fixing 8bit assumptions in internal gimp code, you are
still not touching the plugins. You are still using underneath
it all gimp TileManagers (and so not GeglTile, GeglTileIterator,
or GeglCaches).
In the meantime in gegl you are busy writing generic double versions of
the same set of ops that we evolved to above to support for gimp.
These generic double versions use GeglImage (and so new GeglTiles and
GeglIterators and so on) instead of old gimp TileManagers, and we get
to see how all the new set of things work out.
You could achieve the above with the same set of ops by just having
an abstract GeglImage like you described before but underneath
have one subclass that uses Gimps TileManagers (and gimp caches
and such) for the tile, and have another subclass that uses new
GeglTiles and gegl/image stuff etc. Something like:
GeglImage
GimpTileManagerImage <---- uses stuff from gimp/app/base
GeglTileImage <--- uses stuff from gegl/image
This way you could pass the same GeglImage object through the
graphs but if when the op gets it, it is a version that uses
the old tile manager from gimp, it calls the appropriate
gimp versions of the image processing routines (including
the pixel regions iterator stuff) and if it is one which uses
GeglTileImage new ones it calls the version that
uses GeglTiles, GeglTileIterators, GeglCaches etc.
This means for a while inside your op you have both gimp wrapper
versions of code (these call back to gimp/app/base) and you
have new generic double versions that you are writing to match these
but doing it the new way using GeglTiles, GeglTileIterator, etc.
You then "port" the old versions of gimp code (or write
new 8bit versions) so that you have a full set of 8bit
and double versions of the ops using all new GeglTiles,
GeglTileIterators, etc.
Once you have this you make the switch out of using the old
tilemanagers in your GeglImage and move to the new ones.
This is where all the plugins break but gimp internal stays
okay cause you have already prepared it for this day.
I know it is not as elegant but it avoids ever really breaking
internal gimp too much, which I think might be good.
Calvin
