Partial frame synchronization TODO

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
  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.

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]