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 _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list