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 <c...@chnry.net
<mailto:c...@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@iem.at
http://lists.puredata.info/listinfo/gem-dev
_______________________________________________
GEM-dev mailing list
GEM-dev@iem.at
http://lists.puredata.info/listinfo/gem-dev
