[PD] Syncing an event with refresh rate in GEM

chris clepper cgclepper at gmail.com
Fri Oct 12 20:58:42 CEST 2007


There is one catch to using vsync that not many know about.  This
illustrates it pretty well:

[gemwin 60] with pix_movie playing back a 29.97 fps DV clip:

print: 6.001
print: 27.532
print: 5.823
print: 27.144
print: 6.313
print: 27.383
print: 5.992
print: 28.492
print: 4.613
print: 29.411
print: 3.936
print: 28.189

Note that every other frame pattern.  Why is that?  The low number is
probably a fairly accurate number for the CPU to fetch the frame from disk,
decode and then fling it up onto the GPU for texturing, but what about the
other number?  Add the two numbers together and they are almost exactly the
time for two frames to render (about 33 ms at 60fps).  The reason is that
the driver will wait on the 'no load' frame for the next sync before
returning which is why it runs too long.

On 10/12/07, cyrille henry <cyrille.henry at la-kitchen.fr> wrote:
>
> gemhead 50
> |
> t b b
> | |
> realtime
> |
> print
>
> you should have only 50.
> what i've got is :
>
> print: 46.48
> print: 52.183
> print: 52.213
> print: 46.474
> print: 52.186
> print: 46.505
> print: 52.192
> print: 52.179
> print: 46.512
> print: 52.174
> print: 52.209
> print: 46.484
> print: 52.179
> print: 46.512
> print: 52.159
>
> (with audio off, nothing else than the gemwin and this 4 object in the
> patch)
>
> this jitter make it impossible to compute 1 and only 1 frame for each
> frame on the screen, even with sync on vblank.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20071012/5ad96b84/attachment.htm>


More information about the Pd-list mailing list