Update ensures to paint the next frame in fullscreen mode and attempts* to disable glXSwapInterval for partial repaints.
Performance with glXSwapBuffers is best, not using waitSync() causes flicker in the copySubBuffer case.
I could not cause visible tearing (i fetched a *really* old screen to test this) with glXSwapBuffers but w/o waitSync so i'd just skip that here.
=> In general we should attempt to enter the swapbuffer call, eg. when having full repaints or -ideally- by copying the front buffer into the backbuffer right after the swap (so the backbuffer is always up-to-date and we can just swapBuffers all the time?)

Very interesting thing i could notice here: every now and then glXWaitVideoSync blocks for more than one, sometime even more than two frames.
This is esp. notable when running mplayer, but not so much when running glxgears.
I suspect the client (mplayer) performs a waitvideosync itself, but running "mplayer -nodouble" causes flicker in the video window.
It happens regardless of the GPU and the display (tested on 60Hz TFT and 85Hz CRT)

*intel/mesa throw an gl error for invalid range for a 0 interval - *shrug*

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.