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. 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) so sometime, the screen has to display the same image twice. from my own perception, of an installation i made on osX, this was visible. (small, but visible) when gemrate was set to 70 and screen at 60, sync was perfect, but obvioulsy, pd was not able to generated 70fps, (only 60), so this create audio drop. so, sync to Vblank is mandatory in order to have good images quality, but it's not the only need. the fps sould be exactly the same a your screen (or multiple of this), but you can only an aproximative syncronisation. a perfect syncronisation between gem and the screen could be using a sync to Vblank, and gem fps faster than the screen and in a diferent thread than the audio. cyrille , b > On 10/11/07, cyrille henry <[EMAIL PROTECTED]> wrote: >> >> >> Batuhan Bozkurt a écrit : >>> Roman Haefeli wrote: >>>> On Thu, 2007-10-11 at 18:55 +0200, IOhannes m zmoelnig wrote: >>>> >>>> >>>>> the next thing is to synchronize your trigger events with the >>>>> gem-rendering. >>>>> >>>>> >>>> while we are at: is there some way to hardsync Gem's framerate with the >>>> screen refresh rate? i noticed, that when using [gemwin >>>> <screenrefreshrate>], both are quite >>>> in synch, but not really. i made a patch, that shows a part of an image >>>> with a very width. now, when scrolling the image from right to left >> with >>>> a counter, that is hardsynced to [gemhead], i still see some glitches, >>>> the scrolling is not stable in movement. wouldn't it be cool, to have >>>> an option for [gemwin], that automatically >>>> hardsyncs it to screen refresh rate? [gemwin -1] ? is it possible at >> all >>>> to get 'screen clock' (i don't know how this is called correctly) on >>>> every os? >>>> >>>> roman >>>> >>>> >>> I think this is called vsync(and seen as an option on some systems as >>> ''sync to vblank''). >>> And afaik this is not just tied to the software that is rendering things >>> to screen but to the graphics card driver itself. I'm very frustrated >>> about this in linux and windows. >> well, >> 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). >> >>> First and foremost, Windows XP does not have vsync enabled on desktop, >>> so when you move a window around you will see tearing on sides of >>> windows. This is not enabled in XP and I don't know a way of enabling it >>> actually. I've heard that there was a beta of XP where vsync was enabled >>> as default so I think this is a choice of developers(as it affects >>> performance afair). >>> And GEM is not synced too. You can try with the attached patch. I found >>> no ways of enabling it for OpenGL applications. (I think vista has it >>> enabled by default, did not try it though) >>> >>> In linux, that is another story. Vsync is not enabled by default. You >>> need to have direct rendering enabled to have vsync enabled. If you have >>> a ATI graphics card with closed source drivers and you are using >>> compositing(via XGL), that is not possible. If you are not using XGL, it >>> is not enabled as default. If you have direct rendering enabled, you can >>> use a tool called ''driconf'' to enable vsync. When you enable it, >>> regular desktop is still not synced(move windows and you will see >>> tearing). But GEM(and opengl) will be synced as they are using direct >>> rendering. So you will be fine. >> well, with nvidia driver, you just have to click on the sincr to vbank >> toggle box in order to enable it. >> (and select on wich screen to sync in case of diferent screen frame rate) >> >> cyrille >> >>> On Macos, vsync is enabled both on desktop and opengl by default. It >>> looks smooth and nice, because of that. So you won't see any tearing >>> whatsoever on your desktop or in GEM. This is really nice. >>> >>> You can see the attached example to see if you have vsync on or off. If >>> you are synced, the bar will move smoothly. If not, you will see tearing >>> in movement. >>> >>> In my experiments, XP had tearing and I had no fix, in Ubuntu Linux, >>> tearing by default but can be fixed by driconf, and in osx there were no >>> problems. >>> >>> Batuhan >>> >>> >>> ------------------------------------------------------------------------ >>> >>> #N canvas 0 29 753 593 10; >>> #N canvas 6 63 454 304 gemwin 0; >>> #X obj 67 89 outlet; >>> #X obj 67 10 inlet; >>> #X obj 67 41 route create; >>> #X msg 67 70 set destroy; >>> #X msg 142 68 set create; >>> #X msg 198 112 destroy; >>> #X msg 132 112 create \, 1; >>> #X obj 132 136 gemwin 60; >>> #X connect 1 0 2 0; >>> #X connect 2 0 3 0; >>> #X connect 2 0 6 0; >>> #X connect 2 1 4 0; >>> #X connect 2 1 5 0; >>> #X connect 3 0 0 0; >>> #X connect 4 0 0 0; >>> #X connect 5 0 7 0; >>> #X connect 6 0 7 0; >>> #X restore 39 82 pd gemwin; >>> #X msg 39 63 create; >>> #X obj 45 179 gemhead; >>> #X obj 45 211 rotate 0 0 0 1; >>> #X obj 45 250 translateXYZ; >>> #X obj 190 210 line; >>> #X obj 204 87 bng 15 250 50 0 empty empty empty 0 -6 0 10 -262144 -1 >>> -1; >>> #X obj 202 110 t b b; >>> #X msg 189 176 4 1000; >>> #X msg 255 189 -4 1000; >>> #X obj 241 143 delay 1000; >>> #X obj 330 166 delay 1000; >>> #X obj 47 342 cuboid 0.06 4 0; >>> #X text 199 61 bangme; >>> #X connect 0 0 1 0; >>> #X connect 1 0 0 0; >>> #X connect 2 0 3 0; >>> #X connect 3 0 4 0; >>> #X connect 4 0 12 0; >>> #X connect 5 0 4 1; >>> #X connect 6 0 7 0; >>> #X connect 7 0 8 0; >>> #X connect 7 1 10 0; >>> #X connect 8 0 5 0; >>> #X connect 9 0 5 0; >>> #X connect 10 0 9 0; >>> #X connect 10 0 11 0; >>> #X connect 11 0 6 0; >>> >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> 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 >> > _______________________________________________ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list