Re: ScreenSaverView/NSQuickDrawView/Opaque issue [update]
Re: ScreenSaverView/NSQuickDrawView/Opaque issue [update]
- Subject: Re: ScreenSaverView/NSQuickDrawView/Opaque issue [update]
- From: "Andy O'Meara" <email@hidden>
- Date: Fri, 03 Jun 2005 10:27:38 -0400
Glenn, thanks for your assistance, however--and perhaps I should have been
more clear--alpha stuff isn't needed/desired. I author music visualizer
engines (ever hear of G-Force or WhiteCap?), that complete each finished
frame in an offscreen GWorld. So to be clear, the goal is to get a frame
buffer to a cocoa view the best/fastest way possible. Naturally, the frame
size is on the order of the screen and performance is paramount, so the
myriad of Cocoa and CF's procs/classes for getting a single bitmap to a
NSView are worthless--they all assume you just need a single static frame
(and therefore don't give any consideration to a high performance
situation--or, at least, they don't document anything about it).
Another version of expressing my goal is: whatever method Apple internally
uses to get QuickTime frames ultimately to NSViews is what I'd also like to
do (ie, QT frames ultimately originate in CPU RAM and can be arbitrarily
large, so what is Apple doing to maximize performance and get them to the
screen?). In the wonderful world of Classic/Carbon, CopyBits() was the
ticket, but now of course that's all going away. By the same token,
CPU-based frame rendering folks like me are a dying breed (and being
replaced by openGL folks), so there's not a lot of us out there now. My
company has new visuals in the works (on OpenGL), but it'd be nice to use
G-Force and WhiteCap in Cocoa for stuff like Screensavers and so on.
It'd be nothing to have my engine's output to some other frame buffer--is
there any high-performance/low-overhead way to get a frame buffer that's
going at the order of 30fps to a NSView? (ie, is there a secret replacement
for an offscreen GWorld such that I get get frames to the screen under Cocoa
rapidly? -- I'm pretty sure no). -- I'm dying to know what Apple does for
QuickTime frames.
A short while ago, I filed a documentation/ATN request for the above.
Here's a paste of it:
Title:
Documentation/ATN Request: Performing custom offscreen drawing
Summary:
There's currently good/adequate Apple documentation for making an offscreen
graphics world for the purposes of get direct access to pixel bytes
following Quartz drawing calls (CGBitmapContextCreate), but there is no
documentation about the best/Apple-recommended method for doing custom
offscreen drawing (where custom-created frames would subsequently need to be
shown in a window or cocoa view).
Notes:
Our software performs frame-buffer iterative effects, where each frame is
sent so some onscreen window/view after its been generated. Since the
algorithm has several steps, it cannot be done in-place, so we have a couple
offscreen frame buffers. Of course, under Carbon, we're make an offscreen
GWorld and call CopyBits to get it to its final destination. It'd be great
if Apple could create an ATN or enhanced the existing CG documentation in
order to tell developers like me what the preferred method is (that will
work with at least 10.3--it's great that stuff like CGLayers is available,
but its definitely not reasonable to require users to have 10.4).
Further Clarification:
Myself and other developers realize functions like CGImageCreate() exist, so
my ATN/documentation request is for a high-performance. For example, image
some video engine was producing offscreen frames in a GWorld, and you wanted
to turn it into a Mac OS X screensaver. Clearly, the you'd want to be doing
some CopyBits-equivalent to the most direct backing store possible, etc.
Andy
>>>
>>> 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