Chris and Cyrille, thank you both for this very useful information and ideas for testing etc. I will investigate some more and post results when I get some.
Thanks to all Theo
On 19/07/2012 13:49, chris clepper wrote:
On Thu, Jul 19, 2012 at 6:14 AM, Theo Burt <tb504@york.ac.uk mailto:tb504@york.ac.uk> wrote:
Does anyone know how the vsync works on OSX? I mean how does GEM wait for the vsync, to flip the buffer? Does it block the process at any point? Is the process blocked by any part of GEM at any point, on a per frame basis?VBL sync is a single line of code that turns it on/off. GEM's render engine doesn't do anything different based on that state.
For example, after the all the opengl has been executed, I'm presuming a system call is made to actually render the screen? What is this call, and could it simply be that something, perhaps operating system related, is causing it to take too long to return? That would tie in with moving windows around the desktop making the problem worse...The last call in any GL chain is glFinish() which flushes all of the commands to the card via the driver. The driver can block the uploading of commands to the card for various reasons most of which are not documented anywhere. Apple has OpenGL profiling tools that can show where time is being spent in the driver.