Frame synchronization open questions

[Owen Taylor <otaylor redhat com>]

Some open questions in my head about the frame synchronization work:

* Is GdkPaintClock the right name? It might imply that it only has to
  do about painting and not about other things like layout.
  GdkFrameClock would be an alternative. GdkClock is possible but
  likely too generic.

* For pausing the main event delivery, what we currently do is that
  we queue events but don't dispatch them. This could conceivably
  cause ordering problems for apps that use filters, or for work
  in GDK that is done at the translate stage - since we are not 
  pausing translation, just pausing delivery. Alternatives:

  - Remove the file descriptor and don't unqueue events from the OS
    queue until event delivery is unpaused. Since we can wait and
    sleep currently while event delivery is paused, we have to be
    careful that we don't spin in this case.

  - Unpause event delivery earlier - before we freeze waiting
    for _NET_WM_FRAME_DRAWN. Then we don't need to worry about spinning
    when there are OS events pending, since we'll never sleep with
    event delivery paused.

* Do we need something like GtkTimeline but "rawer" - where you can
  just get updates and a raw elapsed time? Should we make
  GtkTimeline with a negative duration do this with the progress
  being the elapsed time?

* Is it OK for the paint-clock to be an immutable property set at
  GdkWindow construction time? Right now, it's mutable, but not
  notified, and not handled within gtk.

* Right now GdkPaintClockTarget only has a set_clock() method. Would
  it make sense to also have it have a update() method, and have the
  behavior that adding a paint clock target to a widget or directly
  to a GdkPaintClock implicitly requests the ::update phase until
  the target is removed? This would simplify the code in the places
  where I'm using GdkPaintClockTarget currently a bit, but I don't
  see implementing GdkPaintClockTarget directly to be a common thing.