Re: Modernizing the display loop [try 2]

[Benjamin Otte <otte gnome org>]

Owen Taylor <otaylor <at> redhat.com> writes:

> My basic idea is to have a "Window Clock" object that serves as the
> central point of timing coordination for each toplevel window.
> 
Why is this a property of a window? Aren't clocks specific to a screen/display? 
>From the message you sent to wm-spec list it looks like a per-window approach.
Is that just for convenience or do you expect window managers to paint different
windows at different times?

Also, I'm not sure that exposing a separate object is a good idea. Handling
redraws is a feature of a window to me, not something you want to split out.
Unless we expect applications to care about which clock is used with which
window, which brings me to the next point:

Do you expect the clock to be mutable? Because I can't come up with any usecase
for it, let alone a sane way to implement this.

>  /* Get the singleton window clock for a toplevel window */
>  GdkWindowClock *gdk_window_get_clock (GdkWindow *window);
> 
> The window clock object has two signals:
> 
>  ::layout
>  ::draw
>
Isn't the only information the window can provide that a previous paint cycle
has completed and a new paint cycle can now start? So the differentiation
between a "layout" and a "draw" step is an implementation detail that you would
introduce inside GDK that is not a feature of the underlying windowing system,
right?
Because if so, we could hide that step and not expose it in the public API. We
could then do a relayout + paint cycle from expose events internally (inside GTK
probably). And then it almost seems like the only thing a GdkWindow would need
to care about is when to send the next expose event.

Another thing I'm not sure is how toplevel resizes would work with this. Because
in current GTK a relayout means a resize which potentially needs a different
size from the toplevel. And that needs communication with the WM somehow. Did
you spend time thinking about that problem?
 
> It also has can have any number of "clock targets" objects added to it:
> 
>  void gdk_window_clock_add    (GdkWindowClock *clock,
>                                GdkClockTarget *target);
>  void gdk_window_clock_remove (GdkWindowClock *clock,
>                                GdkClockTarget *target);
> 
> GdkClockTarget is a simple interface:
> 
>  struct _GdkClockTargetClass {
>      GTypeInterface base_iface;
> 
>      void (*update) (GdkClockTarget  target,
>                      GdkWindowClock *clock);
>  };
>
> When there is at least one clock target added, the clock is "on", and
> whenever it's time to draw a frame, each clock is updated.
> 
I commented about this on IRC, and it seems to me that this looks like a signal
more than something that needs an interface. Of course, we'd need to have a way
to be notified about signal addition/removal by gobject, but that is a
much-requested feature these days. Or is there something else that makes this
something we should go through to implement a "real" Observer pattern.


One thing that your mail does not touch at all and that I consider quite crucial
is how to handle timing problems. We have a lot of widgets that take their time
and easily take 100ms to relayout or draw. And I'm sure other applications have
those, too. So any solution that we come up with will need to account for that.
Not sure how related that is to your mail though.

And there's all the problems with the current GTK design that Havoc pointed out
in the mail he linked to. I think we'd first need to solve those with the
current API before we can attempt to invent something new. And I'd rather get
this interface right than try to hack it into the current mess we have in GTK.

Benjamin