On 10/01/04, David Neary wrote:
> I think it might be useful for gegl, as well as for the GIMP, to
> have a clear roadmap of things that absolutely, positively must
> get done before the GIMP can use gegl. I don't really know what
> those things are, but I imagine that finishing GeglImage is one,
> although that goal is probably too vague to be a proper
> milestone.
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.
Because the way that gegl's properties and nodes currently work
they can be adapted to pass any kind of data along
as input and output properties providing that kind of
data has an appropriate matching property class that knows
how to deal with it.
So we could write filters that are wrappers around
the image operations that gimp currently has.
That means we use gimp's current TileManager as the basic image type
that is passed along the graph, and the filters that
we create just call the current routines in gimp/app/paint_funcs,
gimp/app/composite, etc.
As an example the code in gimp_image_projection would set
up a tree that looks like this:
P
\
initial_region
/ \
L1 combine_region
/ \
L2 combine_region
/
L3
where initial_region and combine_region are now gegl filter
objects now. (ie they are gobjects)
initial_region's has image inputs src1, src2 and an image
output called dest (There are other inputs (properties)
to this filter too but not shown, ie opacities, masks,
etc, exactly what gimps initial_region routine has now.)
The properties on the initial_region and combine_region ops would
be set up so that things look like this:
TileManager *P = tiles for projection
TileManager *L1 = tiles for L1, first layer
TileManager *L2 = tiles for L2, second layer
GimpInitialRegion *initial = g_object_new(GIMP_TYPE_INITIAL_REGION,
"src1", P,
"src2", L1,
"x", L1->x, /* layer offsets */
"y", L1->y,
...other properties.. /* masks, etc */
NULL);
GimpCombineRegion *combine1 = g_object_new(GIMP_TYPE_COMBINE_REGION,
"src2", L2,
"x", L2->x, /* layer offsets */
"y", L2->y,
...other properties..,
NULL);
GimpCombineRegion *combine2 = g_object_new(GIMP_TYPE_COMBINE_REGION,
"src2", L3,
"x", L3->x, /* layer offsets */
"y", L3->y,
...other properties..,
NULL);
gegl_node_connect (combine1, "src1", initial, "dest");
gegl_node_connect (combine2, "src1", combine1, "dest");
/* Construct the projection */
gegl_node_apply(combine2, "dest");
Then after the apply, the projection tiles pointer is extracted to
gimp's gimage->projection field as a normal gobject style property
like this:
TileManager *projection; /*pointer to gimps image->projection field*/
g_object_get(combine2, "dest", &projection, NULL);
In this case the calls to the op's evaluate method (the main "do it" routine
in gegl) for the initial and combine ops are just covers of initial_region, and
combine_region (we set up pixel_regions in here and the normal composite code
in gimp/app/composite from gimp is called like it is now. No changes
to that code is needed at first).
We would also write image_map ops (just wrappers around the current
image map ops) and stick these in the projection stack above
and have our adjustment layers.
You could even pass gimp "drawables" along the graph
I think if you wanted to write your ops so they passed
this slightly higher level image object.
Of course all memory management, swapping, and so on would just
be the same as it is now in gimp. Actually most architecture
in gimp would stay the same, except just the image operations would
now be done with nodes and graphs. (I think that most of
GimpItem, GimpLayer, GimpChannel, GimpDrawable, GimpContainer,
GimpTextLayer etc would all remain pretty much as they are now.)
I currently have some unit tests that I am going to check in soon
that link with just the following gimp libs:
$(GIMP_DIR)/app/paint-funcs/libapppaint-funcs.a \
$(GIMP_DIR)/app/composite/libappcomposite.a \
$(GIMP_DIR)/app/base/libappbase.a \
$(GIMP_DIR)/app/config/libappconfig.a \
$(GIMP_DIR)/libgimpcolor/libgimpcolor-1.3.la \
$(GIMP_DIR)/libgimpmath/libgimpmath-1.3.la \
$(GIMP_DIR)/libgimpbase/libgimpbase-1.3.la
and will illustrate exactly these ideas. Once those tests are
there maybe we can determine a little better whether this
approach is desirable.
If we do things this way I wouldnt necessarily advocate other
applications should start using these wrapper gimp image ops
or the underlying supporting classes from gimp/app/base
etc as some of this is due to eventually get replaced by
newer versions from gegl/image.
But it would introduce gegl incrementally and allow us to make
an initial gegl transition and get 8bit adjustment and
effect layers before we finally make a big break where 8bit channel
assumptions are fixed and new colormanagement happens, and new tiles,
and so on.
> It would be interesting to have a number of measurable
> milestones, and to start releasing gegl pretty soon. I suppose
> that one of the things that will be needed when releases start
> will be documentation on the philosophy and usage of the library.
Yes. I am working on some gtk-docs for the latest gegl changes
and hopefully those will be in place soon. The current
ones on www.gegl.org are now out of date and several months
old again.
But better docs and examples are definitely necessary.
> What do ye think? Do ye feel that gegl is small enough not to
> have any releases until it's actually at a stage where twe can
> use it? In any case, measuring what's required before we can use
> it is, I think, worthwhile.
>
I guess we need to decide exactly what approach we'll take to
introduce gegl in gimp before we decide how and what to start
releasing.
Calvin
