Emmanuele Bassi 11239d8da6 actor: Do not unmap/unrealize twice on destruction
When calling clutter_actor_destroy(), ClutterActor calls
update_map_state() on itself to unset the REALIZED and MAPPED states,
prior to running the dispose() implementation.

The default dispose() will call remove_child() (either directly or
through the Container implementation), which will check for the MAPPED
state and then run update_map_state() again. We use the previously set
MAPPED state to decide whether or not the parent should queue for a
relayout/redraw when removing a visible children.

If the MAPPED flag was cleared prior to remove_child(), though, it'll
always be unset by the time we get to remove_child(), and this will
cause missing redraws/relayouts; we were ignoring this prior the
post-First Apocalypse changes because we were doing:

  if (was_mapped)
    clutter_actor_queue_relayout (parent);

  clutter_actor_queue_redraw (parent);

which is obviously wrong. Once I removed that glaring brain damage from
the remove_child() implementation, bugs started appearing — bugs that
were probably the reason why we introduced that brain damage in the
first place, instead of checking the source of those bugs.

The obvious fix is to avoid clearing up the actor's state on destroy()
until we remove the actor from its parent. This also reduces the amount
of work we do, and the code paths that can potentially go wrong.
2012-01-31 12:35:17 +00:00
..
2012-01-16 23:37:12 +00:00
2011-11-10 19:05:39 +01:00
2011-11-18 22:06:30 +01:00
2012-01-26 08:31:11 +00:00
2012-01-26 08:30:58 +00:00
2012-01-26 08:31:10 +00:00
2011-06-07 16:06:24 +01:00
2012-01-27 11:55:39 +00:00
2011-10-19 15:23:55 +01:00
2011-10-19 15:23:55 +01:00
2011-11-10 14:13:45 +00:00
2011-06-07 16:06:24 +01:00
2010-10-21 12:22:17 +01:00
2012-01-16 23:35:16 +00:00
2011-06-07 16:06:24 +01:00
2011-12-28 09:37:53 +00:00
2009-07-10 11:38:42 +01:00
2011-10-11 23:42:23 +01:00
2011-06-07 16:06:24 +01:00
2012-01-16 21:06:19 +00:00
2012-01-17 14:29:45 +00:00
2011-06-07 16:06:24 +01:00
2011-06-07 16:06:24 +01:00
2012-01-16 23:49:49 +00:00
2012-01-16 23:49:49 +00:00
2012-01-16 23:49:49 +00:00
2012-01-27 11:55:39 +00:00
2011-06-07 16:06:24 +01:00
2012-01-16 23:35:17 +00:00
2012-01-27 11:55:39 +00:00