On Tue, 2009-08-25 at 12:45 +0100, Emmanuele Bassi wrote: > On Tue, 2009-08-25 at 21:42 +1000, Saul Lethbridge wrote: > > Excellent work! What is the long term plan for Clutter<->Gtk? Will we > > see Gtk depending on clutter in the near future? > > I seriously doubt it, since all the magic is done from the Clutter-GTK > integration library, which depends on Clutter *and* GTK+. > > unless we move the integration inside GTK+ itself, but then calling > gtk_init() would necessarily have to initialize Clutter at the same > time.
I agree, though there are probably some changes to be made in GTK+ classes to allow the development of animated subclasses. I'm not sure if we should be providing a library of animated GTK+ widgets, or leave it up to individual application developers to develop their own animations, I guess it depends if we can think of a stock set of useful animations. > also, there are issues of synchronization of the paint cycle between the > two toolkits that will probably require some special handling. I've been looking into this. From my rudimentary analysis the problem is that a GTK+ expose can preempt Clutter repainting the texture so you can miss an individual expose event (even when it's slower than the vblank). This comes up when you have a number of expose events being handled by GTK+, where the last undoes changes made in the first, each of these expose events is processed before Clutter repaints the texture, even though the events happen slower than the vblank time. Specifically there is also a bug where something occasionally generates a full-actor expose. An example I'm trying to track down looks like this (these are the events as they come in): - button-press-event on GtkButton - expose-event on GtkClutterOffscreen (allocation of button) - expose-event on GtkTable (allocation of button) - expose-event on GtkButton (allocation of button) - expose-event on GtkClutterOffscreen (whole actor) - expose-event on GtkTable (whole actor) - expose-event on all contents of table - damage-event from the first expose (allocation of button) - damage-event from the second expose (whole actor) - expose-event GtkClutterEmbed (this calls clutter_redraw) - button-release-event on GtkButton - expose-event on GtkClutterOffscreen (allocation of button) - expose-event on GtkTable (allocation of button) - expose-event on GtkButton (allocation of button) - expose-event on GtkClutterOffscreen (whole actor) - expose-event on GtkTable (whole actor) - expose-event on all contents of table - damage-event from the first expose (allocation of button) - damage-event from the second expose (whole actor) - expose-event GtkClutterEmbed (this calls clutter_redraw) - paint on GtkClutterActor Running a pure GTK+ example of the same widget tree does not result in the extra whole-table expose. Nor does prelighting due to enter/leave-notify-event. I'm pretty sure that getting rid of this extra expose of the whole tree will at least reduce the frequency of the potential race. -- Davyd Madeley Collabora Ltd., Melbourne, Australia http://www.collabora.co.uk/ -- To unsubscribe send a mail to [email protected]
