On Tue, Jul 17, 2012 at 5:35 PM, Cyrille Henry <ch@chnry.net> wrote:


if you ask Gem to render at 100Fps, you'll have a new image 10ms after last render.
if your screen is rendering at 60fps, it ask for 16.6 ms between 2 images.
so, after having render a frame, gem will wait for the scren 6.6ms on average. everything will be hang during this 6ms.
pd time will desincronize from real time.
that's why the clock from this pd can not be used to compute audio.
but since pd timing is more than 6ms acurate, you can be certain that every computed frame will be rendered for 16.6ms
So this result on using a timing based on the screen.
you can use this pd the send bang to an other pd that compute the sound.


There could be locks on the back buffer when using VBL sync that would prevent anything more frequent than 1/VBLrate to actually render into it.  So you might have a situation like this:

render 10ms wait 6.6ms render 3.4ms render 10ms wait 3.3ms to get two frames.  As I wrote previously, I used to know who to ask to get the actual answer to this, which was great because the GPU people are really secretive about their black boxes.