Indeed, that's a better as it will work on all machines and not
only the ones that support FBOs. Also, passing a FBO to QC would
mean passing a texture name and there's no efficient way to do this.
OK, so this is what I needed to find out - there is no efficient
way of using FBOs with QC presently.
AFAIK FBOs have been around since OpenGL 2.0 so I'm not personally
concerned about backward compatibility. Also FBOs appear to be the
way to perform offscreen rendering moving forward.
Yes, but not all Macs support OpenGL 2.0
Check out the following, looking specifically under CVImageBuffer
- you could use a CVOpenGLBufferRef to perform your desired task,
I would think...
Not as far as I can see... CVOpenGLBufferRef requires an OpenGL
context whereas I think I'd need a CVFBOBufferRef style of function.
If I was to log an enhancement request for a CVFBOBufferRef style
of API would this be something that QC could easily make use of?
You will always need a GL context to do GL rendering, FBO or not.
CVOpenGLBufferRef just require the use of a shared context to attach
to the buffer in order to render into it:
- create primary OpenGL context
- create a second one, shared with the first
- create QCRenderer on primary context
- create CVOpenGLBuffer, attach to secondary context
- draw in secondary context and call glFlush() to ensure drawing
commands have been sent
- detach secondary context with CGLClearDrawable()
- pass CVOpenGLBuffer to QC image input
- render a frame with QCRenderer
Incidentally my real goal here is to render into GPU memory and
then have QC use my image without the image having to move from the
GPU back to the CPU and then back to the GPU. I'm thinking that
FBOs are the way to do this but maybe I'm missing something...
CVOpenGLBufferRefs is exactly what you need
________________________________________________________
Pierre-Olivier Latour email@hidden
Quartz Composer Team Apple Computer, Inc.
