New version of synchronization changes

[otaylor redhat com]

Hi all -

Here's a new set of patches for the WM spec adding synchronization. It's
a fairly minor evolution of the proposal I made in 2011, with quite a bit
more non-normative text added to explain what is going on.

A formatted version of the synchronization chapter can be found at:

http://fishsoup.net/misc/wm-spec-synchronization.html

For easier review.

I'm expecting people to be a bit put off by the complexity of the proposal,
and in particular, by the fact that a particular frame timing algorithm
is recommended (but not required) for the compositor. I'd certainly rather
avoid that, but I found that without some idea of how the compositor
is drawing, it is very hard to write a client that achieves a solid,
consistent, and known latency. (Something that you want when attempting
to play video with perfect audio synchronization.)

Additional information on the question of timing can can be found:

http://blog.fishsoup.net/2012/11/28/avoiding-jitter-in-composited-frame-display/

(See older blog posts for more general background.)

My branches implementing the proposal for GTK+ and GNOME

http://git.gnome.org/browse/cogl/log/?h=wip/frame-synchronization
http://git.gnome.org/browse/clutter/log/?h=wip/frame-synchronization
http://git.gnome.org/browse/mutter/log/?h=wip/frame-synchronization
http://git.gnome.org/browse/gtk+/log/?h=wip/frame-synchronization

(The GTK+ changes are big because I'm introducing the idea of frame-based
drawing from scratch - I'd expect changes for a frame based toolkit like SDL
to be much smaller.)

The one thing from the spec that is unimplemented in the above patchsets
is _NET_WM_SYNC_FENCES - I'll be locating the right hardware/software for
a test environment and working on that soon.

Please let me know if you have any questions, and if anybody is interested
in implementing this for a different window manager or toolkit, I'd be happy
to provide advice and work with you on testing for interoperability.

- Owen