[GEM-dev] Problem with glitching on OS X at high frame rates

[Theo Burt]

Thanks everyone for all their suggestions. Unfortunately, I can't run 
the graphics on  a different thread, as they are so tightly integrated 
with data from the audio thread.

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?

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...

OR, (and this may sound strange), there's no possibility for a denormal 
to creep in anywhere is there? It's just what happens to the system (the 
whole of PD seems to slow down to about 50% while the glitches are going 
on) is particularly reminiscent of denormal issues I've had in the past...


On 17/07/2012 23:15, chris clepper wrote:
> On Tue, Jul 17, 2012 at 5:59 PM, Cyrille Henry <ch at chnry.net 
> <mailto:ch at chnry.net>> wrote:
>
>     oh, on linux you can't render faster than the screen.
>     i supposed that it was the same on osX, but i'm may be wrong.
>     if you can render faster than the screen, then the proposed
>     solution will not work, and i have no other solution, and no
>     explanation for the problem.
>
>
> GEM is certainly sending the GL commands at whatever rate you set, 
> but I honestly don't know for sure what happens in the GL driver and 
> on the GPU when setting the GEM frame rate higher than VBL sync. 
>  Maybe the extra rendering commands are ignored or maybe not.
>
>
> _______________________________________________
> GEM-dev mailing list
> GEM-dev at iem.at
> http://lists.puredata.info/listinfo/gem-dev