Dave Neary wrote:
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.
See, the thing is, I don't think Calvin's plan is the "softly-softly"
approach. Nor do I think it is more gradual.
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.
Well, except you are glossing over huge details.
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.
No, I don't think that is my plan. In fact, CMYK came much much later
in my plan (acording to the roadmap I wrote up). And it can be broken
into small, managable, stable, goal focused steps.
For one thing, the actual data layout doesn't need to change at the
begining. That was part of my goals of my gegl-image design. First you
convert TileManager to GeglImage but use the same data layout as is
currently used. Then the conversion in the gui is a refactoring of the
api (and some rearranging of some assumptions) and the conversion in the
compositing code simply changes the call to get the pointer to raw data.
As this point, the assumptions of the imaging code get cleaned up, no
new features are added, and more or less the exact same files are
touched (and they are _easier_ to change) as in calvins plan.
Basically, calvin is suggesting we change the gui to use gegl ops, and
change the ops to use tile managers and gimp compositing code, while I
am suggesting we touch (less) gui to make it use gegl images, and touch
the compositing code (in minor ways) to get its data from a gegl image.
Further more, we are taking a step _backwards_ to make gegl ops use gimp
compositing code and tile managers, because we need to redo it, or keep
gegl ops seperate entirly to keep gegl's goal of being an efficient,
general image processing system. There is no step backward with my plan.
Next, where are we left after the initial integration? What is the next
step for Calvin's plan? It isn't clear to me. We can't go to layer
effects or adjustment layers. At least not in a general way, because
that requires redisgning the plugins. We could integrate GeglImage, but
now, but that is almost exactly the same as my first step, I do'nt see
how integrating gegl image has gotten any easier because we did this.
We are not ready to go to high bit depth. We are not ready for color
management. We could go for layer groups. Anything else?
However, going for GeglImage first means that we have reviewed the pixel
code for assumptions about color spaces and bit depths, and further, we
have a pixel access system that understands color management and high
bit depths. Further the gimp compositing system already does its work
in doubles, so changing to high bit depth has just gotten much easier.
Color Management is much closer to being achieved because of
GeglColorSpace (and its reliance on ICC profiles). Futher, we haven't
taken a step backwards on gegl ops, so we can now do calvins first step
and integrate gegl ops, only we can integrate the real gegl ops instead
of hacked up gegl ops, and still hit the same changes in the gui. My
point is not that we must do all these things, but that integrating
GeglImage gets us ready to do any of these next steps, and they can even
proceed a good bit in parallel.
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.
I think calvin's plan takes a bigger hit to the core. And no, it won't
necessaraly (though it could) give the big features in the next release,
and it certainly puts us closer to them.
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).
Yes, but how is Calvin's plan any different? How will you avoid forking
a developer branch on gimp, introduce GeglOp, and make it so that it can
first display images with these ops. It is the same procedure.
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.
No it won't. Certainly not everywhere. In GimpLayer, in GimpImage, and
in the compositing functions, we are replacing the base image type with
another base image type. They do more or less the same thing (keep
track of and identify tiles). How does integrating GeglOps not do the
same thing. GeglOps are pretty substantially different, and even in my
plan, it is the integration of GeglOps that is see as the difficult
part. Like I said we don't have to hit the plugins for high bit depth
right away, though it must be done eventually. Also, the plugins should
really bedesigned around gegl-ops, and the plugin setup needs a redesign
anyway (which I am also working on somewhere), and the redesign I have
in mind, that I have discussed with yosh and Sven focuses around gegl
ops anyway.
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.
Right. I strongly believe that the shortest path is my path. I have
spent months (literally) of planning trying to decided how the gimp code
works and it would be best to change it to efficiently integrate gegl.
My entire focus in gegl is based on those observations. The reason I
was getting so frustrated with this thread is that Calvin has half
admitted that he hasn't looked at gimp code, yet is arguing with me
anyway (which I feel has been a pretty ignorant way to argue).
I am terribly concerned that the people reading this thread will like
Calvin's point because he leaves out some of the more gritty details of
his "plan" (which I can only imagine is because he doen't know them),
and that they will reject mine because I talk about more specific work
(and thus it _sounds_ like more work).
At the very least please don't argue another plan until you have taken
at least _some_ time to understand gimps compositing, tile management,
swapping, and display code. Of which there is no reference and AFAIK, I
am the person with something approaching a good understanding of gimps
current system.
--
Dan
