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)


Gimp-developer mailing list

Reply via email to