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 <[EMAIL PROTECTED]> 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@iem.at mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list _______________________________________________ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list