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

[Fred Kiefer]

Am 25.08.2010 19:47, schrieb 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 :-)

Wow, these numbers are quite surprising. I would have thought that the
bitmap image handling code would be a lot slower. That code should be at
least four more method calls per pixel. The bad thing about the NSColor
code must be the allocation and auto releasing of the object itself. Not
much we can do about that.