Doubts about GPeriodic

[Owen Taylor <otaylor redhat com>]

A new GPeriodic class has popped up in GIO that's supposed to be the
basis of a unified master clock implementation between Clutter and GTK+.
I'm skeptical that any abstraction like GPeriodic can provide useful
integration between Clutter and GTK+

The real problem is that the phases of the repaint cycle matter. We
don't just have a bunch of stuff we need to do every frame, we need to
do things in the order:

 * Process events
 * Update animations
 * Update layout
 * Repaint

If GTK+ and Clutter are working together in the same process, then we
still need to go through those phases in the same order and do
everything for each phase.

It looks like GPeriodic has two phases:
 
 - Tick
 - Repair

Which I guess are meant to be "update animations" and "relayout and
repaint". I can sort of see how I can squeeze the right behavior out of
it given various assumptions. In particular, you need to only ever have
one one repair function that does all the work of relayout then repaint
- you can't have separate repair functions for relayout and repaint. Or
for clutter and for GTK+.

But does an abstraction make sense at that point? If we need to
explicitly glue GTK+ into clutter or clutter into GTK+ using hooks
provided in GTK+ and Clutter, then all that GPeriodic is doing is saving
a bit of code reuse.

- Owen