[Prev] Thread [Next]  |  [Prev] Date [Next]

-[NSWindow deviceDescription] contains bogus color space information Kyle Sluder Thu Oct 28 13:00:26 2010

Hi all,

Following all the trials and tribulations of trying to correctly
calculate composited colors, I just decided to punt and let Quartz do
the heavy lifting. Our approach now is to create a CGBitmapContext and
draw into it the colors which we want to composite, then extract those
color components from the resulting bitmap.

I noticed that if we perform our drawing in a bitmap with floating
point components, we get results that are off by one in the red and
blue channels. I'm assuming this can be attributed to different
rounding behavior for floats versus integers. I originally chose
floating point components because I want to create a CGColorRef out of
the bitmap data, and the constructors take float arguments. But
because we need our calculated values to exactly match the results of
overlaying a transparent CALayer of one color atop an opaque CALayer
of the other as well as the results of drawing the same colors into a
window context, I need to be absolutely sure that the bitmap context
we use for compositing exactly matches that which Core Animation uses
for -drawLayer:inContext: as well as its own compositing.

But NSViews don't have any color space or bit depth properties, so I
can only assume NSWindow is in charge of that. (Heaven help me if Core
Animation doesn't track the window's color space.) So I ask the view's
window for its -deviceDescription. Here's the result I get when I log
the result of calling [[self window] deviceDescription] from within my
view's -drawRect:, even when I have set the window's
displaysWhenScreenProfileChanges to YES:

    NSDeviceBitsPerSample = 0;
    NSDeviceColorSpaceName = NSCalibratedBlackColorSpace;
    NSDeviceIsScreen = YES;
    NSDeviceResolution = "NSSize: {72, 72}";
    NSDeviceSize = "NSSize: {480, 382}";

This is obviously incorrect.

Am I barking up the wrong tree? How should I create my bitmap context
so that I'm sure that it's performing the same math with the same
rounding behavior that I would get both by drawing to the
system-provided context in -drawLayer:inContext: as well as what Core
Animation does internally when it calculates the color of a pixel?

--Kyle Sluder
Do not post admin requests to the list. They will be ignored.
Quartz-dev mailing list      ([EMAIL PROTECTED])
Help/Unsubscribe/Update your Subscription:

This email sent to [EMAIL PROTECTED]