On Tue, Jul 17, 2012 at 5:35 PM, Cyrille Henry <[email protected]> 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.
_______________________________________________ GEM-dev mailing list [email protected] http://lists.puredata.info/listinfo/gem-dev
