On Fri, 2007-10-12 at 20:17 +0200, cyrille henry wrote:
Roman Haefeli a écrit :
On Fri, 2007-10-12 at 00:48 +0200, cyrille henry wrote:
Thomas O Fredericks a écrit :
"sync to vblank will sync swapping buffer with the screen frame rate, but that's not the original question. to my knowledge, there is no possibility to sync gem rendering with the screen frame rate. if you fix both at 60Hz, you can have jitter (not a lot, but some)."
You are not technically syncing gem to the screen frame rate.
yes
You are syncing the open gl redraw to the framerate.
yes
The GPU takes care of that.
i don't understand this.
if you get gem to render a 60FPS, you will have 60fps based on the pd (cpu) clock.
i don't know this by reading the code, but for me it would only make sense to get the clock from the audio-card, nothing else. this is also what i experienced, when pd was running on jackd, while jackd was believing to be running at 44100Hz, while it was actually at 48000Hz. all [metro]s were too fast and all pitches too high. the only objects, that seems to work not with the audio-clock, that come to my mind, are [cputime] and [realtime] (is that true?)
if you set your screen at 60fps, you will have 60fps based on the gpu. there is no way to make the cpu clock to be exactely the same speed as the gpu clock. so, sometime (specially with big patch), you can have desincronisation between this 2 clocks, even if they should be at the same speed. (there is a also a lot's of jitter in pd clock)
what makes you think that? i 'd claim, that pd's clock is stable, unless you get audio drop-outs.
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.
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).
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, 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'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