Re: [Gnustep-cvs] r31195 - in /libs/gui/trunk: ChangeLog ColorPickers/GSWheelColorPicker.m Source/NSColorPanel.m

[Eric Wasylishen]

> Now this is not fair :-( I specifically asked to not use the
> NSBitmapImage method as this is horribly slow (I did write it, so I
> should know). What I wanted you to test is use the colour conversion
> from NSColor. In this case create an NSColor object and ask it for the
> RGB values.
>
> NSColor c = [NSColor colorWithCalibratedHue: h saturation: s
>  brightness: v alpha: A];
>
> [c getRed: &r green: &g blue: &b alpha: &A];
>
> I just want to know whether this is also prohibitive slow, or if we
> could recommend this as a general solution.

Actually, I made a mistake in my previous test and forgot to create an
autorelease pool around each row of image processing.

With the autorelease pools,

NSColor c = [NSColor colorWithCalibratedHue: h saturation: s
brightness: v alpha: A];
[c getRed: &r green: &g blue: &b alpha: &A];

takes 380ms, and

[bmp setColor: [NSColor colorWithCalibratedHue:h saturation:s
 brightness:v alpha:A] atX: x y: y];

takes 415ms, so it's not so bad after all (vs 100ms for the current code).

> And of course we should also think about ways to make all that code
> faster :-)
>
>> I agree the hardcoded HSV->RGB conversion is ugly here.. but it looks
>> like using ObjC message sends for each pixel of an image is
>> prohibitively slow. I agree in the long run we want real color space
>> handling (ICC profiles etc.) and I started implementing this in Opal
>> over the summer... which I'll talk more about in the report I'm
>> working on :-). So I would say we should live with the ugly code for
>> now because of the big usability improvement, and maybe in the future
>> delegate the conversion to Opal or a colorspace handling part of
>> GNUstep.
>
> At the moment I don't see any Opal code that would help here.

Not directly. What I wanted to say is that since HSV is just a transformation
of RGB to cylindrical coordinates, it's still in an RGB color space. So our
color wheel could be in sRGB, or AdobeRGB, or whatever color space we want.
Opal will handle that (delegating it to LittleCMS).

> And in the
> long run Opal and gui should use the same code in most places anyway. At
> least this is what I hope.

Yes, I agree.

Cheers,
Eric