Roman Haefeli a écrit : ... >> this jitter make it impossible to compute 1 and only 1 frame for each frame >> on the screen, even with sync on vblank. > > yo, i trapped my self by measuring with [timer]. > > anyway, if you calculate the average of these values, you'll come pretty > close to 50ms (49.9094 to be accurate, though adding another 52.xx value > will give you a result slightly above 50). yes. > > i cannot see that as a prove for your statement, that this would make it > impossible to show exactly one frame on each screenrefresh. let's say > each gem render cycle happens just half in between each screen refresh > tick, how could that be possible without syncronisation?
>then the jitter could be almost 30ms in both directions without > showing the same frame twice or leaving out one frame. > > i made a patch, that scrolls an image, whose pixel grid matches the > pixel grid of the gemwin, by shifting the image an integer pixel value > on each gem render cycle and i got an (almost) perfectly smooth and > glitchfree movement, which is for me the empirical proof, that gem is > able (or at least comes close) to show exactly one frame on each screen > refresh tick. since gem and the screen apparently use different clocks, > as mentioned in previous posts, this probably won't be true in the long > run. i think we agree : "almost perfect" is not "perfect"... cyrille > i'd rather to not want to send the patch to list (because of the weight > of the images), but if you want i could send it to you privately. > > roman > > > > > > > > ___________________________________________________________ > Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de > > > _______________________________________________ > 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