Re: ScreenSaverView/NSQuickDrawView/Opaque issue [update]
Re: ScreenSaverView/NSQuickDrawView/Opaque issue [update]
- Subject: Re: ScreenSaverView/NSQuickDrawView/Opaque issue [update]
- From: glenn andreas <email@hidden>
- Date: Fri, 3 Jun 2005 08:58:15 -0500
On Jun 3, 2005, at 8:40 AM, Andy O'Meara wrote:
On 6/3/05 9:29 AM, "glenn andreas" <email@hidden> wrote:
On Jun 3, 2005, at 8:17 AM, Andy O'Meara wrote:
So that folks like me may benefit, I wanted to share my root
issues/mysteries (and this doesn't just apply to screen savers--if
you use
NSQuickDrawView, this is also for you). I apologize in advance if
some of
there are novice Cocoa comments/mysteries... If anyone can shed
some light
on the following issues, I'd be very grateful.
Quickdraw (and by extension, NSQuickDrawView) has absolutely no
concept of alpha/transparency in bitmaps. While it can store an
extra byte that would, in theory, be usable for an alpha channel,
it's value is often overwritten with even simple quickdraw
operations. The end result is that transparent views/windows do not
support quickdraw (this is even true under a purely Carbon approach -
you need to use CoreGraphics if you want anything other than a solid
rectangle (though some things do support clipping regions, but that
doesn't solve the problem)).
Yes, that's why it's humorous (and frustrating) that changing my
NSQuickDrawView's isOpaque to return YES results in its drawRect()
never
getting called.
Andy
Indeed, that is strange (and frustrating)...
If you really need to use quickdraw, I'd scrap using an
NSQuickDrawView, and instead figure out some way to keep track of
transparency manually, and either use CoreGraphics or NSDrawBitmap
(or NSBitmapImageRep).
If your alpha data is just "I want white pixels transparent,
everything else opaque" you can walk through your gworld after
drawing and convert 32 bit xRGB pixels to 32 bit RGBA pixels, and
then use NSDrawBitmap (or build an NSImage/NSBitmapImageRep). If you
don't feel like messing with swizzling pixels (because you need to
keep that gworld intact for later drawing) you can do something
skanky like making sure that the bitmap is just a pixel wider, and
then pass the base address of the bits + 1 to NSDrawBitmap (since it
wants RGBA instead of ARGB - you'll fix your alpha in the pixel
afterwards).
If your alpha data is more complex (i.e, you are doing a lot of
CopyDeepMasks to build up an image), you'll need to keep a secondary
grayscale gworld with the alpha values (and build it up as you
manipulate the regular gworld - it's pretty ugly, but it does work).
There is then (IIRC) a way to tell CoreGraphics to use this parallel
structure as the alpha (or you can just manually fold these alpha
values in like above).
Basically, NSQuickDrawView is one of those "stopgap" type of measures
- I wouldn't be surprised if you weren't getting "This is deprecated"
console log messages when using it under Tiger (since Tiger seems to
love to generate deprecation warning log messages).
Glenn Andreas email@hidden
<http://www.gandreas.com/> wicked fun!
Widgetarium | the quickest path to widgets
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden