Re: Frame synchronization open questions

[Alexander Larsson <alexl redhat com>]

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

I agree that Paint is confusing, GdkFrameClock seems to be the right
name to me. Frame is what this is always called in gameloop style code.

> * 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:

Are you sure that is really a problem? The x11 gdk_event_source_check()
code will never even look for a message if there is any GdkEvent queued.
And if there is nothing queued _gdk_x11_display_queue_events() will stop
as soon any X event was converted to a queued GdkEvent. And, since this
queued event will not be read due to the pause we will never process more
X events until resume events.

So, we may process multiple events that are not queued into gdk events and
at most one that is queued, but no more until the queued event is handled. 
This does not look like it could ever cause a reordering problem to me. At
most it means we may handle some filtered X events during the frame cycle, 
I'm not sure that is as much of a problem.
 
What I do however worry about is the combination of multiple GdkPaintClocks
and gdk_display_set_events_paused(). It seems to me that each paint clock
assumes it has full ownership of the display, calling set_events_paused(FALSE)
whenever it has finished its paint cycle. However, could there not be other
paintclocks (say for another toplevel) being active at that time?

Another thing I worry about is offscreen window animation. If you have an window
with an embedded offscreen inside, then queueing a redraw on a widget inside the
offscreen will cause a repaint cycle. When drawing to the offscreen this will
generate damage events that will cause the embedding widget to repaint itself.
However the damage events will be emitted during the paint phase, and the parent
widget will not get these until the next frame. This will cause a delay of on frame
which may look weird.