compiz paint clock needs to be smarter
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Compiz |
Fix Released
|
Medium
|
Unassigned | ||
compiz (Ubuntu) |
Fix Released
|
Undecided
|
Unassigned |
Bug Description
Looking into http://
* handle damage
* reset paint clock to process next redraw at 1/framerate interval
* repaint scene
* wait for vblank
* glXSwapBuffers
My guess is that we want to be able to do sane frame limiting while also hitting the vblank on time. The frame limiting stuff is rather primitive in that we wait for the 1/framelimit interval before redrawing the screen. It might be more useful to immediately redraw the screen in antcipation of the next vblank and keep the timer running to *cap* these redraws if they're going over the frame limit.
Changed in unity (Ubuntu): | |
status: | New → Confirmed |
Changed in unity: | |
milestone: | 4.2.0 → 4.4.0 |
Changed in unity: | |
milestone: | 4.4.0 → 4.6.0 |
Changed in unity: | |
milestone: | 4.6.0 → 4.8.0 |
Changed in unity: | |
milestone: | 4.8.0 → none |
affects: | unity → compiz |
affects: | unity (Ubuntu) → compiz (Ubuntu) |
For compiz, this is really two bugs:
1. The delay was much too long, causing frames to be skipped. Fixed in 0.9.7.0 (bug 880707 et al).
2. Waiting for vblank. "Hitting vblank on time" is a non-issue once we have glXSwapBuffers always on --> bug 901097. swap_control instead.
Because there is no client-side wait for vblank once we can use GLX_SGI_