Hello
I find myself in a situation where i need to drive the output of two
QCRenderers (possibly each on rendered a different display) with the image
output of a singular QCRenderer.
I am aware of the tech-note stating that QCRenderer itself is not thread safe ,
and usage on a CVDisplaylink / secondary thread implies you will alloc/init it
and clean it up from that one thread , and never move or call it from a
different thread. That said, is it possible and ok to retain the output of
QCRenderer (valueForOutputKey: ofType:@"QCImage") and use it on a thread other
than the one it was calculated on?
My ideal situation is essentially:
Main CVDisplayLink:
A: QC Renderer -> take some input and render out "result image"
B: QC Renderer -> Display result image with some processing
Second CVDisplayLink:
A: QC Renderer -> Display above "result image" with different
processing.
It seems CIImage is somewhat more able to deal with this can QCImage
(requesting output as CIImage vs QCImage). On that note, I know it was
mentioned before, but in 10.6, requesting a CVOpenGLTexureRef is no longer
possible, correct? I ask because that might be a workable solution, as OpenGL
textures are allowed to be read across threads (and shared contexts), does the
same hold true for the QCImage opaque type?
Due to the complexity of the first QCRenderer, its not a possible solution to
re-calculate the "result" image on the second display. My solution currently is
ignoring timing on the second display and using only 1 CVDisplaylink. I'd like
to avoid that solution.
Thank you for any insight.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Quartzcomposer-dev mailing list (Quartzcomposer-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/quartzcomposer-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
