compiz paint clock needs to be smarter

[Sam Spilsbury]

Looking into http://blog.fishsoup.net/2011/06/13/benchmarking-compositor-performance/ it seems as though we are doing a few things on damage events in compiz:

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

[Daniel van Vugt (vanvugt)]

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.
Because there is no client-side wait for vblank once we can use GLX_SGI_swap_control instead.