[PD] Syncing an event with refresh rate in GEM

[Roman Haefeli]

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