[Cogl] [PATCH 3/3] Add CoglFrameTimings

[Owen Taylor]

I wanted to write down some points in email for reference - we discussed quite a bit
of stuff in detail on IRC:

* The specifics of the current proposal for how notifications work don't
  work out because the assumption that the swap completes and all timing
  information is instantly available isn't generally true. It's only true
  when swapping directly to the front buffer.

  If you look at:
  http://owtaylor.files.wordpress.com/2012/11/tweaking-compositor-timing-busy-large.png

  the arrow from the compositor to the application represents the time
  when the application can meaningfully start the next frame. If the
  application start drawing the next frame before this, then you won't be
  throttled to the compositors drawing, so you may be drawing multiple
  frames per one compositor frame, you may also be competing with the
  compositor for GPU resources.

  This arrow is probably the best analog of "swap complete" in the
  composited case - and being notified of this is certainly something that
  a toolkit (like Clutter) written on top of Cogl needs to know about. But
  the time that "presentation" occurs is later - and the compositor needs
  to send the application a separate message (not shown in the diagram)
  when that happens.

  This idea - that the frame proceeds through several stages before it is
  presented and we there is a "presentation time" - drives several aspects of my
  API design - the idea that there is a separate notification when the
  frame data is complete, and the idea that you can get frame data before
  it is complete.

* Even though what I need right now for Mutter is reasonably minimal -
  the reason I'm making an attempt to push back and argue for something
  that is close to the GTK+ API is that Clutter will eventually want
  to have the full set of capabilities that GTK+ has, such as running
  under a compositor and accurately reporting latency for Audio/Video
  synchronization.

  And there's very little difference between Clutter and GTK+ 3.8 in
  being frame-driven - they work the same way - so the same API should
  work for both.

  I think it's considerably better if we can just export the Cogl
  facilities for frame timing reporting rather than creating a new 
  set of API's in Clutter.

* Presentation times that are uncorrelated with the system time are not
  particularly useful - they perhaps could be used to detect frame
  drops after the fact, but that's the only thing I can think of. 
  Presentation times that can be correlated with the system time, on
  the other hand, allow for A/V synchronization among other things.

* When I say that I want timestamps in the timescale of
  g_get_monotonic_time(), it's not that I'm particularly concerned about
  monotonicity - the important aspect is that the timestamps 
  can be correlated with system time. I think as long as we're doing
  about as good a job as possible at converting presentation timestamps
  to a useful timescale, that's good enough, and there is little value
  in the raw timestamps beyond that.

* If we start having other times involved, such as the frame
  time, or perhaps in the future the predicted presentation time
  (I ended up needing to add this in GTK+), then I think the idea of
  parallel API's to either get a raw presentation timestamp or one
  in the timescale of g_get_monotonic_time() would be quite clunky.

  To avoid a build-time dependency on GLib, what makes sense to me is to
  return timestamps in terms of g_get_monotonic_time() if built against
  GLib and in some arbitrary timescale otherwise.

- Owen