On January 24th, 2012, 7:09 p.m., Martin Gräßlin wrote:
Is this one committed?
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.)?
- Thomas
On November 10th, 2011, 4:30 p.m., Thomas Lübking wrote:
|
Review request for kwin and Martin Gräßlin.
By Thomas Lübking.
Updated Nov. 10, 2011, 4:30 p.m.
Description
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
|
Testing
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.
|
Diffs
- kwin/composite.cpp (aa721b8)
- kwin/options.cpp (19c3ee5)
- kwin/scene.h (d8bcf48)
- kwin/scene.cpp (413e46f)
- kwin/scene_basic.h (a087eb5)
- kwin/scene_basic.cpp (cc8dbdd)
- kwin/scene_opengl.h (e13d8a5)
- kwin/scene_opengl.cpp (47015b3)
- kwin/scene_opengl_egl.cpp (22e082c)
- kwin/scene_opengl_glx.cpp (ddebcd0)
- kwin/scene_xrender.h (6c916c8)
- kwin/scene_xrender.cpp (3618d79)
- kwin/workspace.h (4d7fda5)
- kwin/workspace.cpp (6a8e2df)
View Diff
|