Tagged: QCRenderer single-thread issue
November 12, 2010 at 7:38 am #5054Andrea CremaschiParticipant
Amazing! I am really impressed and excited about your work..
@vade, could Syphon be someway used as a workaround for QCRenderer single-thread limitation (there is a Apple QA about it: http://developer.apple.com/library/mac/#qa/qa2008/qa1538.html)?
ie: I would like to call Syphon from my application thread, let it negotiate the opening of a QC composition on a new thread and get access to a (CIImage *) handler for further graphic (pixel per pixel) processing. Is it possible?
Thanks for your great efforts!
a. c.November 12, 2010 at 8:51 am #5055vadeKeymaster
You can init and run QCRenderers from multiple threads (like, a CVDisplayLink thread), but you have to be sure to init them, call executeAtTime and dealloc them all from *the same* thread. You cannot bounce them across threads.
So you can have multiple QCRenderers on multiple threads, assuming they never leave where they were alloc/initted from.
Syphon does not init or run QC Compositions / QCRenderers in the framework, its agnostic on rendering back ends, as long as its OpenGL based 🙂 So it cant help you with regards to opening compositions.
To be clear however, you can setValue: forInputKey from values that come from different threads. IE, if you render a comp, get out a CVOpenGLBuffer image from it, you can then move that to another thread. I dont think that should leak, as you are responsible for cleaning up the value of the output key. You do need to retain it, and ensure locking happens in threaded scenarios.
I believe that is correct, some software does use QCRenderers on threads other than the main thread without issue.
Is that information useful?November 12, 2010 at 9:31 am #5056
As an addendum – if you were thinking of using a new-frame handler in a SyphonClient to achieve this, you shouldn’t make any assumptions about the thread the new-frame handler will be invoked on – assume it could be invoked on any thread, and that invocations for the same SyphonClient may happen on different threads.
As vade says, you can use QCRenderers on background threads, so long as each renderer doesn’t cross threads.November 12, 2010 at 11:46 am #5057Andrea CremaschiParticipant
Thanks for the replies! They have been really useful. So the point is I have some more Core Video and thread management to study !
And good work on Syphon, I’ll keep in touch and I am looking forward to the stable version!November 12, 2010 at 12:02 pm #5058vadeKeymaster
Well, not to toot our own horns, but thanks to Toms amazing work Syphon is very stable. We’ve got absolutely 0 crash reports from anyone so far that are actually caused by Syphon. We urge you to try it out before the full 1.0, which, at this point is probably only going to be a few small API additions.July 24, 2013 at 9:11 pm #26889
What if I want to get the pixel values out of a syphon client? (into a custom image processing application) ?July 25, 2013 at 2:26 am #26891
Ideally do all your processing in OpenGL and leave the pixels on the GPU, but if you absolutely must get at them, draw into an FBO, get the pixels from that. Using glGetTexImage() on a SyphonImage directly won’t return useful pixel data – it’s a limitation of the underlying IOSurface.July 25, 2013 at 6:00 am #26892
Would that be like rendering a texture into a bitmap image? I could reduce the resolution (since my application wont require too much) on the render target.
I know nothing about OpenGL, or what it is an ‘FBO’ right now. I am more into OpenCV. Would you advise me some tutorial to start up on that?
Thanks!July 25, 2013 at 9:53 am #26893
The OpenGL Super-Bible is a useful book. I’m sure google will turn up a lot of tutorials.August 1, 2013 at 8:24 pm #27762
uugh, is there a shortcut for that?
Any help would be appreciated!August 2, 2013 at 8:21 am #27887
I did it using Cinder. This is just a part of the project so I could not spend too much time learning openGL and objective C (where my troubles are). Thanks for the support!
Syphon is just great!
- You must be logged in to reply to this topic.