V-SYNC causes choppy animations.

Hello,

My JOGL application is currently running at about 1000 fps. I wanted to sync the framerate with my monitor refresh rate (60hz). I tried adding gl.glSwapInterval(1); in my GLEventListener's init() method, and this does limit the framerate to 59-60 fps, but all the animations now look choppy. If my monitor updates once every 1/60 of a second and my application updates every 1/60 of a second, why does the application look so much better when running at 1000 fps. Shouldn't 1000 fps look exactly like 60 fps since the monitor only updates 60 times a second?

My OS is Ubuntu 12.04, and I have an ATI graphics card with the fglrx 12.10.5 drivers.

Hi

It probably comes from your code but if you have a doubt, run the pre-beta version of TUER, enable the v-sync in the options and confirm that the animations aren't choppy. If you keep the OpenGL context current longer than required to perform some operations or if you perform useless costly context changes, it can cause some "choppiness". A typical loop iteration should follow these steps:
- update the timer(s)
- update the data model(s)
- render

Only the very last step requires a current OpenGL context. If you don't feel comfortable with that, use an high level solution, there are several 3D engines that support JOGL 2 including Ardor3D and JMonkeyEngine.

Be more precise about your graphics card.

Thanks for your reply.

I don't quite understand what you mean by keeping the OpenGL context current longer than required.
Do you mean that I should not perform some OpenGL calls, do some heavy calculations in Java and then perform some more OpenGL calls?

In my program, I initialize a variable that points to the OpenGL context in my GLEventListener init() method and use that context for the entire life of my program . I don't think this is recommended. Could that be causing problems?

I tried running TUER with vsync on and off. With it off, it ran at ~115 fps and looked choppy and had tearing. With it on it ran at 60 fps, and looked better and there was no tearing, but it still looked choppy (not as choppy, though).

The GLXGears demo runs at 60 fps and looks super smooth.

Here are further details about my video card:
SAPPHIRE TOXIC 100282TXSR Radeon HD 5850
1GB 256-bit GDDR5
PCI Express 2.0 x16
HDCP Ready
CrossFireX Support

You shouldn't put everything into the display() method. You shouldn't store GL and GL instances into fields, you should get them each time you need them by using GLContext.getCurrent() and GLContext.getCurrentGL(). The tearing is not surprising but it is still choppy. Do you reproduce this problem with other OpenGL applications except GLXGears?

I just realized something, the choppy animation occurs when it is being controlled by my mouse. If I run GLXGears, the spinning gears look smooth, but when I start moving the orientation with the mouse, it gets choppy. That is also what was choppy in TUER: The panning of the camera with the mouse.

I tried running my program with vsync on Windows 7 and the mouse driven animations were super-smooth, but lagged behind the mouse a significant amount.

I reproduced your last problem once on a laptop under Windows 7 when using the touch pad some months ago but it wasn't reproducible on the same machine under Mageia Linux 2.