• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: ScreenSaverView/NSQuickDrawView/Opaque issue [update]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: ScreenSaverView/NSQuickDrawView/Opaque issue [update]


  • Subject: Re: ScreenSaverView/NSQuickDrawView/Opaque issue [update]
  • From: glenn andreas <email@hidden>
  • Date: Fri, 3 Jun 2005 09:41:26 -0500


On Jun 3, 2005, at 9:28 AM, Andy O'Meara wrote:


Sorry, 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?).

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


It appears that CVPixelBufferCreate will work with something very similar to the bits that are produced in your offscreen GWorld, so it looks like a good fit with your existing pipeline.

CoreVideo is probably overkill if you just want to refresh a small NSView in a window from a GWorld, but since you're doing full screen video, this is probably going to be your best bet...



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


  • Follow-Ups:
    • Re: ScreenSaverView/NSQuickDrawView/Opaque issue [update]
      • From: "Andy O'Meara" <email@hidden>
References: 
 >Re: ScreenSaverView/NSQuickDrawView/Opaque issue [update] (From: "Andy O'Meara" <email@hidden>)

  • Prev by Date: Re: ScreenSaverView/NSQuickDrawView/Opaque issue [update]
  • Next by Date: Re: Programmatically determining number of arguments a selector takes
  • Previous by thread: Re: ScreenSaverView/NSQuickDrawView/Opaque issue [update]
  • Next by thread: Re: ScreenSaverView/NSQuickDrawView/Opaque issue [update]
  • Index(es):
    • Date
    • Thread