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 <[email protected]
<mailto:[email protected]>> 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.
_______________________________________________
GEM-dev mailing list
[email protected]
http://lists.puredata.info/listinfo/gem-dev
