On January 24th, 2012, 7:09 p.m., Martin Gräßlin wrote:

Is this one committed?

On January 24th, 2012, 9:48 p.m., Thomas Lübking wrote:

Nope. Neither the actual swap, nor the nvidia framerate selection.
For the latter, i shall have a look on XFree86-VidModeExtension, for the former - maybe we can actually move the gl renderer into its own thread if we rely on Qt4.8 (waiting alongside a mutex for the next sync, when the mutex is open -> render. Otherwise skip that frame.)?

Concerning Qt 4.8 my understanding of the thread on kcd was that people want to go for keeping Qt 4.7 as the minimum build dependency. But if we could present this (with a working in worst case ifdef-ed solution) as a valid reason, maybe this would change :-)

- Martin

On November 10th, 2011, 4:30 p.m., Thomas Lübking wrote:

This performs a paint & glFlush immediately after the buffer swapping and defers the next swapping to the next anticipated frame (or idling)
The behavior is still not as deterministic as we hoped to be since we cannot measure the time for the actual vsync :\
I set a fuzzyness of 6ms what leads to a majority of 2-3ms times in waitsync but single wait times up to 8 or 9ms occur (what ultimately can be part of the syncing itself)

There's some debug code to print lagging.

TODO:
- attempt egl support
- probably lie to the effects about the time

I've used a CRT for testing which can sync every 11ms ie. 85Hz and lowered the maxFPS down to 10fps with pretty constant results for the time lost waiting for the sync.