On Thu, Jul 19, 2012 at 6:14 AM, Theo Burt <span dir="ltr"><<a href="mailto:tb504@york.ac.uk" target="_blank">tb504@york.ac.uk</a>></span> wrote:<div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
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?<br>
</blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
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...<br>
</blockquote><div><br></div><div>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.</div>
<div> </div></div>