Hi,
First, I'd just like to say that I've really enjoyed this thread. It's
been an interesting discusion, and apart from the fact that there is a
bit of frustration creeping in, it's been cool.
Calvin Williamson wrote:
On 21/01/04, Daniel Rogers wrote:
I don't see what this gets us. What features does it enable us to add
to the gimp? The most highly requested "big features" like high bit
depth support, CMYK and color management require us to change all the
pixel access stuff first. The only thing I can see this as getting us
is a simplification of procedural layers.
Its just a way of doing things that is more gradual, its just
the difference between refactoring towards something and
re-writing it completely. Both are candidates you might choose.
Seems both approaches have drawbacks and advantages.
For what it's worth, the softly-softly approach is the one I would
advocate. Perhaps Sven, yosh and mitch have other ideas, but since it's
been over 3 years since 1.2, I would like to have more regular releases.
And that means keeping the GIMP CVS more or less usable more or less all
the time.
Some of the work for the migration (setting things up so that
integrating gegl ops can be factored in easily, for example) can be done
in the 2.2 release, but I think it's best not to anticipate too much for
that release.
Afterwards, a 2.4 or 3.0 could include, say, nodes doing layer
compositing, and perhaps layer groups and adjustment layers (which would
be pretty straightforward if we use gegl for rendering), and then
swapping over from TileManagers to GeglTileCaches or whatever could be
done after that release.
That's the Calvin plan, and I have to admit it has its charm.
The alternative is to take at least 6 months (and that's probably
ambitious) to convert the image and data structures completely to gegl
in the core, do the UI for CMYK and extra bitdepths, and have a 3.0 over
a year after a 2.2 release. Then migrating the layer system and
projection code to GeglNodes would be a smaller job, and would be done
for a 3.2 release in a couple of years.
This also has some things going for it - at some stage we're going to
have to take the hit converting the core. And this gives us the big
features in the next stable release. But it means having a fairly
unstable core for some periods, I think.
my point is the gimp gets ported to GeglImage while gegl gets its ops
working and then, when gimp is finished is ready, move in GeglOps.
Moving the other way means that while Gegl is tuning its op stuff for
its new image model, gimp is grafting the ops into its old image model.
These cross-purposes sound like they are oging to cause collisiosns.
So just to be clear, are you saying first fork a developer branch on gimp,
introduce a GeglImage into gimp and make it so that it can first
display these kinds of images, and then port all the ops
to GeglOps, meanwhile merging back and forth changes from
a main branch where any UI or other work is being done.
So a ground up re-write, yes?
Unfortunately, this sounds that way to me too. I see (perhaps I'm
mistaken) the graph subsystem and the image subsystem of gegl to be more
or less distinct - while graphs will apply to image data, it is more or
less arbitrary how this image data is represented (sure, GeglNodes will
need some changes when dealing with GeglImage data instead of tiles and
buffers as they are now, but those changes will have little or no effect
on the code which is using the node system at that point).
However, replacing app/base by gegl's image data structures will require
fairly extensive changes everywhere else in app - and that's without
exposing any extra stuff in the pdb and more or less not touching
plug-ins (the question of how useful the GIMP will be if all plug-ins
work on 8 bit data while we're 16 bit or 32 bit float internally is
another issue), which sounds to me like a pretty big job.
Personally, I prefer the path which allows us to integrate gegl with the
shortest periods of instability possible in GIMP CVS. I would prefer to
avoid a situation where we have a devel branch where we do devel
releases, and a gegl integration branch which is mostly unusable for
long periods. That means that the change to GeglImage will inevitably
impact on gimp development, and it would be nice if it weren't this
year, given how long we've been in a devel cycle.
Cheers,
Dave.
--
Dave Neary
bolsh@xxxxxxxx
