I've always used VBL syncing, but since it's so simple to just activate it and forget it, I never took the time to have a proper look at it.

I can't seem to find this in the documentation, so...

When CGLFlushBuffer() is called with VBL syncing enabled. What exactly happens?

a. The function returns immediately and the flushing happens in parallel?
b. The function blocks the thread that called it and unblocks it when it's time to flush?
c. The thread runs wild in a while loop while waiting?
d. Something else?

I'm guessing ( hoping? ) that the answer is b...

Thanks

the answer is a combination of a) and b). You have a certain number of frame buffers (2-3) available to you for flushing into; if one is available flush will return immediately and the swap will happen later. If none are available, flush will block until one becomes available.

Yes. So, because it can block, if you need to squeeze out as much performance as possible, you should spawn another thread for your physics/AI/whatever that can run independent of the graphics thread.

You can also (as shown at WWDC 2003) have two GL threads running in parallel, for example one calculating and updating texture maps, and one submitting terrain geometry using those textures. In this case you have to use locks if you are sharing one context between the threads (or risk a kernel panic!) Or, you could use a separate context per thread; one could be a render-to-texture context.

Thanks guys, This is along the lines of what I had in mind.