On May 16, 2005, at 11:51 AM, Scott Thompson wrote:
If your code is reading in images, and those images are tagged as
sRGB, when the application draws the images to the screen, they
will have to go through a color management step. That color
management step takes some time.
The images are png files - they're output from Photoshop and I
believe they're tagged as sRGB - however I wasn't seeing the visual
appearance I expected when using the DeviceRGB color space for my
context, bitmaps etc. hence the change to using a specific colorspace.
Your best bet would be to read the images and perform the color
management on them once, then repeatedly draw the modified images.
There are several strategies you might take to do this.
If you support 10.3 and above, you can probably get away with
using CGImageCreateCopyWithColorSpace. As you read in each image,
create a copy and change the color space to the generic RGB space,
or the color space of your monitor.
10.3 is our minimum, so this sounds like the best trick to avoiding
the performance hit.
If you are working on 10.4, then you might find some advantage to
drawing your UI elements into a CGLayer.
I'm already doing this for other drawing speed improvements (using
weak link and a runtime check so that it doesn't get used on 10.3) -
I'll look further into the other color space manipulations too.
Or you could talk your UI designers into using a color space other
than sRGB :-)
Actually - I had an attempt at convincing the market folk that their
screens were just turned up too bright. A Dilbert moment and it
almost worked 8-)
Scott
Andrew 8-)
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Quartz-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/quartz-dev/email@hidden
