After a day brute force of using QCRenderer, an NSOpenGLView and a
pthread, all is working. There is a dramatic speed and performance
increase. I have to profile it but it is faster than I have ever seen
these compositions run. It seems that most of the QC api is
unfinished. For example, you can't directly load a Composition into a
OpenGLContext with QCRenderer as it only takes files so you have to
use its initWithCGL counterpart. I am using the utility classes that
find compositions in the system directories that implement the
MusicVisualizer protocol and these only return Composition references
not File Names. Not a whole lot of extra code to do that, but seems
inconsistent for an api. I have created a scriptable AudioUnit for
using music visualizers. It is one component of a larger project.
The fact that QCCompositionLayer and QCView both render on the main
thread is a really big problem. If you only have one window, this
shouldn't be a problem. If you app is drawing in other places or you
have lots of controls that need updating, the main thread is going to
choke your Quartz Composition. I can't believe Apple implemented it
this way. If anything, it should run in its own thread. I tried to
get it to work by creating the layer in a new thread but that caused a
lot of strange behavior and memory problems with strange crashes. The
only thing that seems to work is to do it all from scratch which isn't
such a big deal. The only thing I have to figure out is how to make
it work in a layer so I can take advantage of other CoreAnimaiton
features.
Thanks
Josh
On Jul 6, 2009, at 11:58 AM, Christopher Wright wrote:
What is the proper way to insure that the animation updates as fast
as possible? The alternative seems to set up your own OpenGL
context and create your own QCRenderer.
As far as I've seen this is the only alternative. Possibly creating
the layer on a separate thread? Perhaps then the timer will also
live on that thread. (I've honestly not worked with CA extensively
in a threaded environment to know the pitfalls that await you there).
Is there a way to grab the renderer from a QCCompositionLayer and
put it in its own thread? Or, is the best way to brute force it
and go back to the manual way of setting up a QCCompositon in an
OpenGL context.
There's no officially supported way to get a renderer from the
layer. you can get its context (-renderingContext private method),
but that's not particularly helpful. So Tthe latter, while
requiring a bunch more work, might be a better solution (assuming
that the timer isn't tied to the creating thread, mentioned above).
--
[ christopher wright ]
[email protected]
http://kineme.net/
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Quartzcomposer-dev mailing list ([email protected])
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/quartzcomposer-dev/archive%40mail-archive.com
This email sent to [email protected]
