[PD] Syncing an event with refresh rate in GEM

[cyrille henry]

hello,

i'm not 100% sur i agree with your analyse.
could you test the same patch without Vsync?


if the driver wait for the "no load", introducing a 26ms frame.
the next "no load" will be 1 frame latter: i.e. 16.6ms
but the next frame is 6ms latter.

i'm wondering if the explanation is not : 
16ms after the laste frame, pd try to render a frame, but rendering took 10ms, introducing a 26ms frame.
pd clock is then 10ms late regarding the real world clock, so it try to compensate. the next 16ms will be only 16-10=6ms. so 6ms latter, pd try to render a new frame. this frame is quite easy to draw, as the image was already decoded, so there is no delay.

cyrille

chris clepper a écrit :
> 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.
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> PD-list at iem.at mailing list
> UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list