Jonas Dreßler 0ba15df57c clutter/stage: Don't do newly queued relayouts after allocation cycle ... While it's strongly discouraged, it is possible to queue a new relayout of an actor in the middle of an allocation cycle, we warn about it but don't forbid it. With the introduction of the "shallow relayout" API, our handling of those relayouts silently changed: Before introducing "shallow relayouts", we'd handle them on the next stage update, but with the priv->pending_relayouts hashtable and the priv->pending_relayouts_version counter, we now do them immediately during the same allocation cycle (the counter is increased by 1 when queuing the relayout and we switch to a new GHashTableIter after finishing the current relayout, which means we'll now do the newly queued relayout). This change in behavior was probably not intended and wasn't mentioned in the commit message of 5257c6ecc2, so switch back to the old behavior, which is more robust in preventing allocation-loops. To do this, use a GSList instead of GHashTable for the pending_relayouts list, and simply steal that list before doing the relayouts in _clutter_stage_maybe_relayout(). https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1267		2020-06-16 09:39:43 +00:00
..
clutter	clutter/stage: Don't do newly queued relayouts after allocation cycle	2020-06-16 09:39:43 +00:00
.gitignore	clutter: Remove clutter specific version	2018-11-06 17:17:36 +01:00
meson.build	clutter: Move tests to src/tests	2019-08-24 08:59:08 +00:00