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. _______________________________________________ Gnustep-dev mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnustep-dev
