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

[Fred Kiefer]

Am 24.08.2010 22:49, schrieb Eric Wasylishen:
> Hi Fred,
> The problems I was trying to fix here is that changing the color wheel
> brightness and resize the color wheel window was quite slow with the
> default color panel size, and got unbearably slow if you made the
> window bigger.
> 
> On my computer (2.3 ghz core 2 duo, Windows) with my newly committed
> code it takes 100ms to render the color wheel at its maximum size (I
> added a max size for the color panel in this patch, previously it was
> unlimited). Changing the rendering to use this line:
> 
> [bmp setColor: [NSColor colorWithCalibratedHue:h saturation:s
> brightness:v alpha:A] atX: x y: y];
> 
> instead of current inline color space conversion and pixel
> manipulation increases the time to 4.4 seconds! For reference, drawing
> the same size wheel the old PS code took 5.3 seconds. So the message
> send overhead is huge in this case. At the max size, the wheel is
> 474x476, or about 250k pixels, and given that the setColor: and
> colorWithCalibratedHue: calls probably involve at least 5-10 sends,
> we're looking at millions of message sends.

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.

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. And in the
long run Opal and gui should use the same code in most places anyway. At
least this is what I hope.

> Regarding the mouse code, I didn't have a good reason to change it
> other than it seemed more complex than it needed to be. But I have no
> problem with changing it back if you want.

Keep it, if you think the current code is a bit better than the old one.
I just did not see the reason for the change, but this isn't enough to
restore the old code.