Re: Answers to some comments about frame synchronization

[Alexander Larsson <alexl redhat com>]

Some more feedback:

Cut and paste doc bug:
 * @GDK_FRAME_CLOCK_PHASE_FLUSH_EVENTS: corresponds to GdkFrameClock::flush-events. Should not be handled by 
applications.
 * @GDK_FRAME_CLOCK_PHASE_BEFORE_PAINT: corresponds to GdkFrameClock::flush-events. Should not be handled by 
applications.
The last one should be before-paint

Did you try this on win32? The default timer resolution there is ~16msec which
is about the 60Hz frame rate, which seems like it can cause some framerate
instability. Its possible to temporarily raise this resolution by calling 
timeBeginPeriod() although its frowned upon to always do this as it raises
total system cpu use. Maybe we could hook this up to the default paint clock,
so that whenever we're doing regular animations we increase the timer resolution.

I see that GtkTickCallback got a bool return value similar to GSource, which is
bound to have the same kind of confusion wrt what value does what. Maybe we
should have the G_SOURCE_REMOVE/CONTINUE equivalents already from the 
start to avoid this confusion.

I think the motion compression is still mishandling motion events from
different devices, so that if you get two motion event streams for the
same window from two devices they will be compressed together. 
Also, there seems to be no compression of touch events, which seems kinda
wrong, does it not?

But in general i think we should land this ASAP and work it out from there.
The new APIs look good to me and we desperately need this as we're starting
to play more with animations in Gtk+ in general.