On 08/24/2010 04:20 AM, David Gowers wrote: > I hope you're not associating the quite suboptimal way in which GIMP > currently uses GEGL, with BABL's speed or lack of speed. > > BABL just processes raw pixel buffers. A converter function just > accepts a source and a destination pointer, along with a pixel count, > and should convert that number of pixels. It doesn't have any heavy > architecture or processing, aside from what may be in each individual > converter function > > looking at your code in gimpcolorspace.c, making that code work with > BABL looks like it's pretty much a case of cut+paste, modify the way > the input is referred to, add some registration code. > > (getting your layer mode code to USE that, is a different issue, and I > agree that would be non-trivial, although you might get significant > speed gains from it because of greatly reduced function call overhead > -- probably about as much as you describe for inlining below.) As I indicated, I'll be happy to make the babl integration of those conversions my next little project, but I also expect a bunch of questions to come up in the process (color management comes to mind). On the other hand I see bablification of gimp_composite_* as part of a general overhaul of that code, not limited to the LCH layer modes. And that raises the question if that makes sense or if that time wouldn't be better spent on the GEGL modes. > I only have one thing to criticize about this patch: It adds a single > whitespace error :) Ha, I believe 'single' is a new positive record for me... :o) Regards Rupert _______________________________________________ Gimp-developer mailing list Gimp-developer@xxxxxxxxxxxxxxxxxxxxxx https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
