Partial frame synchronization TODO

[Owen Taylor <otaylor redhat com>]

Here's the dump of my current  TODO list for finishing up the frame
synchronization work. If things on this list are things you
want to work on, speak up - there's more here than I'll be able to do in
any short amount of time.

Major Stuff Inside GTK+
=======================

* Implement paint synchronization for the OS X backend. This basically
  means that after we submit a frame we want to use CVDisplayLink to
  find out when it makes sense to start drawing the next one.

* Implement paint synchronization for the Window backend. It's less
  clear how to do this - I suspect there are some sensible approaches
  using DwmGetCompositionTiminginfo() and QueryPerformanceCounter() to
  figure out an appropriate time to sleep before drawing the next
  frame, but it would take some experimentation.

* Implement paint synchronization for the Wayland backend. This may
  be straightforward if the protocol already has the right messages
  for frames being drawn, or may require protocol extensions.

? Implement paint throttling for the Broadway backend.
  (I'm not sure what this means exactly - the default
  throttling to 60fps may be OK.)

* When there is a frame where no painting ends up being done, we still
  at the moment are sending increments to the frame serial and waiting
  for_NET_WM_FRAME_DONE. It may be worth tracking when we are about to
  damage a toplevel window (by drawing or configuring it) and only at
  that point start a frame. Then we'll avoid asking the compositor to
  tell us when it's done painting a frame that involves no painting.

Minor stuff inside GTK+
=======================

* Rename GtkTimeline:progress-type to GtkTimeline:timing-function
  and sync definitions to be exactly the same as CSS if
  they aren't.

* Make GtkIconView, GtkTextView, GtkTreeView do the pre-layout
  layout handling in an ::update handler (is this right? should
  it happen after ::update and before redraw? connect-after
  to ::update?)

* Consider whether GtkIconView/GtkTextView/GtkTreeView should
  do the incremental validate step in ::after-paint rather than
  in a low priority idle. Doing it in a timeout means that an animation
  could completely starve animation.

* Figure out what to do with GtkEntry::recompute-handler

* Right now, we do "scan scrolling" (that is, dragging past the
  end to scroll) by adding a timeout and periodically advancing
  a jump that's influenced by how far the pointer is off the end.
  We possibly should do this scrolling in an ::update handler
  instead and make it smooth by advancing by a velocity * time rather
  than a fixed jump.

  (GtkComboBox, GtkIconView, GtkMenu, GtkTextView, GtkTreeView)

* Make GtkWindow not ever call gdk_window_process_updates() and
  always work within the paint cycle.

* Handle switching to a different window manager when we are pending
  waiting for _NET_WM_FRAME_DONE - I think this can cause a hang,
  though it may be that we'll always get an UnmapNotify signal.

Outside GTK+
============

* Fix up Metacity, Mutter, gnome-canvas (evolution, gcompris,
  any other cut-and-pastes), WebKit for adding idle handlers
  either between GTK_PRIORITY_RESIZE and GDK_PRIORITY_REDRAW
  or at GDK_PRIORITY_REDRAW - this never really worked, and will
  work less well now.

* Do a good job on integration of GtkClutter with this system -
  both directions of embedding to figure out what API changes
  are needed.

* Hook up GStreamer to the paint clock - find out if any changes
  are needed.