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. _______________________________________________ gtk-devel-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/gtk-devel-list
