> With GEGL, this will be done through a scale node, like "gegl:transform",
> in the image graph. The code to manage this probably will not end up in
> about the same size as what you have already, except it will use GEGL API
> instead of GIMP's pixel region APIs. We have already ported the projection
> to GEGL, so simply look at the existing GEGL code (git grep gegl_) and
> extrapolate to get a good estimate on how a "gegl:transform" node would be
> added to the graph.

Is this projection already usable by the GIMP interface?  I used the old way
because I thought that the GEGL functionality was only through the special
menus and not integrated into the GUI yet.  The purpose for my patch is to
improve my workflow so I was going for what I can make work today.  I'll
start reviewing the GEGL code.  Looks like it GEGL has support for
multithreading?  I just got a quad-core and I'm anxious for it to improve my
productivity wherever possible.

> And while I'm at it I can mention that your code have some coding style
> issues. Introducing an abbreviation like "nd" for "non-destructive" is too
> short-sighted, so it is better to spell that out. Otherwise we will forget
> what it stands for. And the opening brace for
> gimp_group_layernd_update_scale() is not on a separate line. This is not a
> problem if it's a local drop-in functionality hack of course.

Thank you for the styling suggestions.   I have not made many contributions
to OSS projects yet and I still need some work in this area (as well as my C
skills and my GTK knowledge is nil).  I'll be implementing these changes as
you suggested.  I'll need to tackle some of the GIMP special interface
controls too.  These text boxes are ugly in style and in the code.

Gimp-developer mailing list

Reply via email to