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.
-Joseph
_______________________________________________ Gimp-developer mailing list Gimp-developer@xxxxxxxxxxxxxxxxxxxxxx https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
