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 11:14:59 -0400
Hmm, interesting. The developer part of me is happy that something like
CoreVideo can address my needs, however, the part of me that has to tell my
mac os customers they need to upgrade to tiger is very concerned. I'd have
a lot less of a problem a year from now, but to require it now is a
heartbreaker, especially for something just like a screensaver. So in
summary, thanks for the CoreVideo recommendation--I'll have to get into
that, but I can't require Tiger just yet...
That said, thanks for your time and assistance with this. If you or anyone
here has any further insight into the three questions/issues I posed a few
messages ago, that'd be great too. It'd be especially great to have someone
chime in on why NSQuickDrawView is clearing the frame each time (rather than
just leaving whatever is there). If I can address that issue, than I can
deploy my ScreenSaverView (that uses WhiteCap and G-Force) as early as next
week (something my mac os users have been asking for for a long time) and I
can work on a CoreVideo implementation for Tiger users. If I can't fix
this, I'll have to recopy my entire offscreen frame to NSQuickDrawView on
each drawRect call when I don't need to (often, only a small rect--or
nothing at all--is dirty), making performance stink when it doesn't need to.
I guess what kills me is that the source to the AppKit classes isn't
publicly available, causing non-cocoa gurus (like me) to be discouraged by
having to play guess-and-check all day (the standard practice for Win32 and
MFC development)--at this point, pretty dispirited with regard Cocoa. Would
Apple stand to lose anything from making the core NS* classes source
publicly available? The answer seems to be no, but perhaps I'm wrong.
Thanks,
Andy
>>
>> 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?).
>
> A whole bunch of things, depending on a whole bunch of variables
> (from video card to size of image) - and most of them involve
> directly talking to the video card or going through the Quartz
> compositor (depending on the system version, Quartz Extreme, etc...),
> and most places can't devote the amount of resources required to
> cover all the different combinations and permutations to try to
> reproduce this.
>
> However, Apple appears to have heard your pleas - you should run, not
> walk, to CoreVideo:
>
>
>> What is Core Video?
>>
>> Core Video is a new pipeline model for digital video in Mac OS X.
>> Partitioning the processing into discrete steps makes it simpler
>> for developers to access and manipulate individual frames without
>> having to worry about translating between data types (QuickTime,
>> OpenGL, and so on) or display synchronization issues.
>>
>> Core Video is available in:
>>
>> Mac OS X v10.4 and later
>> Mac OS X v10.3 when QuickTime 7.0 or later is installed
>
_______________________________________________
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