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