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.
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.
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;