they are all using GWorlds so slow performance but hopefully updates
soon. Can the faster "Quicktime visual context" mode be used if an
App
is written in Carbon and C or is this option only available to Cocoa
Objective C apps?
afaik all the interfaces to QCRenderer which is what you'd use to
render a composition manually, are written in Objective C, so you'd
need to use this for your apps, but I don't see any reason why that
would be a problem.
Actually, Roger is talking about playing compositions through QuickTime
visual contexts (note that their are two limitations compared to QC
APIs: no communication with the composition - parameters passing /
retrieval - and no user events - mouse, keyboard, tablet...). In that
case, the API are QuickTime API, so plain C.
Switching to QT 7 visual contexts improves performance and quality a
lot for movies playback BUT it requires the host application to handle
OpenGL textures directly, so that will be a problem for VJ apps that
are not OpenGL aware. If you use Quartz Composer to render on screen,
there this is no problem: see the Performer sample code in
/Developer/Examples/Quartz Composer.
native triggering of QC comps, including controllable parameters.
my question again, is this option available only to Cocoa apps?
The API is Obj-C and can be used from C programs easily - basically
it's all about wrapping the Obj-C code between:
NSAutoreleasePool* pool = [NSAutoreleasePool new];
//Obj-C code goes here
[pool release];
The QuickTime component that allows compositions to be used in
QuickTime does exactly that: QuickTIme is a C environment and Quartz
Composer is an Obj-C API.
is this possible? can a running Quartz Composer patch read in a
texture
stream from the main host application that is changed on the fly?
Yeah, if you see the Performer example, the app takes a movie, gets
the frames one by one and feeds them into the compostion. Provided you
can generate a texture stream in the form of an Quicktime movie or
NSImage, then you can feed this into the composition "on the fly"
That's right. Besides, supported input images formats are: Core Image
images, Core Graphics images, Cocoa Images and Core Video Buffers, so
that's pretty flexible.
it should be no problem as I understand it to have a host application
adding or removing a series of QC patches to a rendering pipeline,
right?
If you want to do it programmatically, I think you'd have to create
multiple instances of QCRenderer, one for each composition, and you'd
extract the rendered image for each and pass it around to another
composition, but that might get a little processor intensive, as I
haven't tried multiple QCRenderer instances yet. You'd most likely
have to disable the renderers you aren't using (or just set it to not
call renderAtTime:)
Indeed, that's the way to do it. Indeed, QCRenderers are very
low-overhead around a composition - there are no problems here.
