Re: paint clock

[Matthias Clasen <matthias clasen gmail com>]

On Sat, Oct 2, 2010 at 10:43 AM, Havoc Pennington <hp pobox com> wrote:

> Adding Paint Clock to GTK+
> ===
>
> The attached patch shows some initial effort to do this. It introduces
> a simple paint clock object. and initially implements it with an idle
> that works like the current GTK+ idle.
>
> A problem I'm running into is that the paint clock's semantics just
> don't really support the current GTK+ API:
> * the resize and redraw idle priorities are exposed, and some code
> relies on this to basically do before/after resize/paint hooks.

If we move to a fixed order of doing things each frame, like Owen
described here:
http://blog.fishsoup.net/2009/05/28/frames-not-idles/ , then the paint
clock could perhaps just have those before/after hooks as signals (as
you already have for paint). If we make animation, input handling and
relayouting a fixed part of the frame cycle, then it is not really a
'paint' clock anymore.

> In my patch the basic approach is to allow setting a paint clock on a
> GdkWindow and the idea is that the clock applies to all children of
> the window that don't have their own clock set. There's a default
> paint clock used for toplevels with no custom paint clock set.

Does it make sense to set a paint clock on anything but a toplevel window ?
Also, if you tie relayouting to the clock as well, does it make sense
to have different clocks on the different windows in the widget
hierarchy ?

> I think the patch needs the paint clock to be a bit more involved; it
> needs to be able to control relayout behavior and what happens on a
> manual process_updates, perhaps.
>
> Some questions to think about:
> * should we do a paint clock at all or just hooks to let containers
> reroute queue_draw/resize coming from their children
> * should the default GTK+ paint clock remain the idle-based approach
> or even without GL should we go to something that's more of a forced
> timeline rather than an idle
> * should manual process_updates even be allowed? drop/no-op this API?
> Or let a window's paint clock decide whether to allow it?
> * does it work to have a separate paint clock on a non-native
> (client-side) window? I should just try it, from the code it isn't
> apparent to me whether painting the parent of a client-side window
> will mess up the pixels of the client-side window. i.e. is it required
> to repaint a client-side window anytime you paint its parent? If not
> should we fix that (clip the client-side window out of parent paint if
> it has a different clock) or should we just say that you can't set a
> clock on a client-side window?
> * should it be possible to override the global default paint clock, or
> only per-window?
> * should the paint clock replace the resize idle also? (I think yes)
>
> Another note is that I put the clock in GDK, because I think a
> Clutter/GDK backend is interesting and right now the paint idle is in
> GDK also.