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@chnry.net mailto:ch@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