Re: Frame synchronization open questions

[Alexander Larsson <alexl redhat com>]

On tor, 2012-10-04 at 15:46 -0400, Owen Taylor wrote:
> On Thu, 2012-10-04 at 08:09 -0400, Alexander Larsson wrote:
> > 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.
> 
> That gets into the details of exactly how I implemented event pausing,
> but logically speaking, if event delivery is paused, and a new event
> happens, it needs to be queued up in GDK, Xlib, or in the X server.
> If we don't translate events, then either:

If we start to translate and queue multiple X events into the gdk queue
there is a lot more risk of the translation getting things "out of
order", so i don't think that is quite safe. So, yeah, queuing in xlib
seems better.

>  * Event is queued in Xlib, XPending() starts returning TRUE
>  * Event is queued in XServer, the file descriptor 
> 
> Either situation is going to make us start spinning currently. But leaving
> that aside, we *need* to translate events or we'll never get _NET_WM_FRAME_DONE
> and unfreeze event delivery.

We could find it via XCheckIfEvent, although that risks not being able
to find it if the server side fd is full when its written and we never
read from the X fd. Not sure if that can happen.

> My current preference is to just unfreeze all event delivery at the end of
> drawing the frame, and not wait for _NET_WM_FRAME_DONE. Then we can make
> pausing *really* pausing - not unqueue, not translate, etc. I don't see
> any real disadvantage of doing things that way.

I agree. This seems clearly safest.

> > 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.
> 
> Hmm. So your concern is that the connection between the embedded
> offscreen and the embedder is purely at the GTK+ level - if GDK_DAMAGE
> events are not delivered to GTK+, then the the embedder won't know to
> repaint.

Actually, it depends a bit on how the event freezing works. Damage
events for offscreens are "emulated" (to make it work even without
damage X support and on other platforms) it the sense that
gdk_window_process_updates_recurse does:

  if (gdk_window_is_offscreen (window->impl_window) &&
      gdk_window_has_impl (window))
    _gdk_window_add_damage ((GdkWindow *) window->impl_window,
                            expose_region);

Which will queue a gdk side event (i.e. X and X event translation is not
involved). So, if we freeze at the gdk level we will not get these
during the paint cycle, but if we do it at the X level we might.

> So the offscreen will generally paint during the wait for
> _NET_WM_FRAME_DONE, and immediately get incorporated into the next
> output frame. Though once things get loaded down and slow, there is no
> guarantee of this.

Yes, there will always be a delay of one frame for the embedded side vs
the embedder side.

> To do better than this, I think you need to slave the clock for the
> offscreen into the clock for the window that is embedding it. If the
> size of the embedded widget is free-floating and not constrained by the
> allocation of the embedder, then the slave clock would simply do the
> complete cycle inside an ::update handler. If you want integration
> of size-negotiation, then you'd have to do different phases at different
> points in the master clock cycle.

Maybe the widget could manually ensure the offscreen widget gets the
same clock at construction time. But thats not really enough is it? You
have to guarantee that the embedded widget draws before the embedder.

> And yes, the delivery of damage as events is problematical for that kind
> of slaving - maybe we would need to have a signal on GdkOffscreenWindow
> to allow getting as-it-happens notification of damage.

Yeah.

Also, for something completely different. With the frame based motion
compression we should imho completely remove the motion hints support.
There is a bunch of code in the csw stuff to emulate it which becomes
pretty much useless with this. And we never pass on motion hint masks to
the xserver anyway since we only get events on the toplevel and motion
hints are generally enabled on some subwindow.