We have a mechanism to trigger repick after animations on
clutter_actor_set_final_state(), but this will not happen if
animations are disabled.
In this case, shell transitions and other typically animatable
changes on the transform of actors will not naturally trigger
a pointer repick when those get instantly changed to the final
state, possibly preserving the cached state and missing the
just popped in actor altogether.
Trigger an instant repick on animation-less transform changes,
so that these situations are also handled correctly, and the
pointer drops the cached state and is able to find the new
actor.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2918
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3168>
With the ClutterEvent subtype structs sealed, this remains the only useful
struct type that is now usable on the Javascript side. Make all
ClutterActorClass event vmethods use ClutterEvent, and update all users
to this change.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3163>
If an actor's expand properties haven't been set explicitly, its
expand flags are computed by traversing its children.
However we currently also traverse into children when explicitly
setting "expand" to FALSE, because that is the default value and
the properties are only marked as explicitly-set when the value
actually changed.
Fix this, so propagating expand flags can be stopped without
hacks like
```c
g_object_set (actor, "x-expand", TRUE, NULL);
g_object_set (actor, "x-expand", FALSE, NULL);
``
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3088>
The stage already maintains its own list of stage-views via
clutter_stage_peek_stage_views(), it's a bit superfluous to copy that list
around all the time into priv->stage_views of ClutterActor. Let's deal with
that by returning clutter_stage_peek_stage_views() when
clutter_actor_peek_stage_views() gets called for the stage.
In order to make sure ClutterActor::stage-views-changed still gets emitted
correctly for the stage, always emit that signal on the ClutterStage when
the stage views get invalidated. This now depends on the backend only
actually invalidating the views and calling
clutter_stage_clear_stage_views() when things have actually changed, but
that should be the case.
This needs a change in one of the stage-views tests, namely the one which
tests stage-view-changed emission on the stage: Here we now see an emission
of stage-views-changed, but that signal emission actually seems correct.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2679>
While we're now doing a fairly good job at not needing those matrices
all the time anymore, we still need it multiple times during every paint
cycle, so it definitely makes sense to introduce some caching here.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2679>
With commit 5a565b42586abb0c851888b827ffabc0cce38b75, we changed
clutter_actor_finish_layout() to be not only about updating stage views,
but also take care of updating the visible_paint_volume, for that we
started doing a full tree traversal of all mapped actors.
This can be quite a performance issue, apparently especially on certain
ARM devices, where the simple tree traversal can take as long as 2ms.
This is precious time we need to paint our next frame, so lets do a bit
more work to avoid those useless traversals.
Fixes https://gitlab.gnome.org/GNOME/mutter/-/issues/2459
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2679>
Using a list of heap allocated ClutterPaintVolumes adds quite a bit of
unnecessary overhead: It means for every single redraw clip we allocate a
list and a paint volume on the heap.
Let's avoid all those heap allocations by using a GArray with static
ClutterPaintVolumes instead.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2679>
So far our logic for queueing redraws goes like this: Actor notices that it
needs to redraw -> actor tells stage that it needs to redraw via
clutter_stage_queue_actor_redraw() -> stage collects more and more redraws
into a QueueRedrawList before the actual stage update happens -> when
that happens, the stage collects the actual redraw clips from the actors via
clutter_actor_get_redraw_clip().
The logic behind this QueueRedrawList was that by storing a list of
redraw entries on the stage, way we can avoid traversing the whole actor
tree one more time to build the redraw clip before the stage update.
These days we have clutter_actor_finish_layout() though, which is basically
exactly that, a whole actor tree traversal that happens before every stage
update.
Since we have that now, we might as well get rid of the whole dance back and
forth between ClutterStage and ClutterActor, and simply merge the logic to
queue redraws into the finish-layout step.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2679>
If no actors have changed their positions and we're only repainting
because a window needs a repaint, the paint volumes of all actors
remain unchanged. There is no reason to redo those paint volumes on every
stage update.
So introduce caching and invalidation logic for the visible_paint_volume
that allows us to avoid a ton of matrix multiplications that right now
are happening for the whole mapped actor tree on every redraw.
Note that this removes two places where the visible paint volume is set
to an empty paint volume: This is a compromise so that we can keep
around the cached pv when hiding and showing an actor, it does "regress"
one case though: When hiding -> moving -> showing an actor, we'll now
include the old paint volume of the actor in the redraw clip on show (even
though redrawing that old region is not necessary, the actor was hidden
after all). This results in a bit of overpaint in this very specific case,
but for the sake of simplicity let's not care about that.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2679>
For now, it goes the "easy" way of creating the root node and
immediately painting and destroying it. From now on, the main
root node is created only by ClutterStage itself.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3007>
We'll soon introduce a new gesture tracking framework which heavily
depends on ClutterActions seeing all events of a sequence. For this to
work, a larger change to event delivery is needed: Implicit grabbing of
all events for button and touch press->motion->release sequences to
ensure ClutterActions continue receiving events for the whole sequence.
This commit takes care of that: At the start of an event sequence we
collect all the event-handling actors and actions to a GArray that lives
in the PointerDeviceEntry, and then deliver all events belonging to
that sequence to the same actors/actions until the sequence ends.
To avoid events getting pulled from under our feet when mutters event
filter returns CLUTTER_EVENT_STOP, this also introduces private API
(maybe_lost_implicit_grab()) on ClutterStage so that we can't end up
with stale sequences.
Note that this also slightly changes behavior when it comes to event
delivery to actions: Because we now store actions separated from their
actors, any action returning CLUTTER_EVENT_STOP now stops event
propagation immediately. That was different before, where we'd emit
events to all actions of the actor and only then stop propagation.
Note that this isn't handling ClutterGrabs correctly right now,
this will be a little tricky, so we'll take care of that in a future
commit.
To handle actors getting destroyed or unmapped during a grab, listen to
notify::grab on the deepmost actor in the implicit grab tree. This gives
us a notification when any actor inside the tree goes unmapped.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2342>
A fairly small refactor, move the emission of events to actions from
clutter_actor_event() to stage level.
We do this because in the future we'll need to know on stage level
whether events were handled by an actor or by an action.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2342>
_clutter_actor_handle_event() currently allocates a new GPtrArray on the
heap for every single event emission, let's avoid this by keeping an
array around in ClutterStage and reusing that.
This is moving the last few bits of event emission into ClutterStage,
which will be useful when we introduce implicit grabbing in subsequent
commits.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2342>
When we remove a child, we stop its transitions (animations), but we
didn't stop animations on grand children. What we did, however, was to
clear the stage views of the grand children, and this caused a bunch of
orphaned transitions (ClutterTimeline) and accompanied warnings.
Make it so that if we stop transitions, and clear stage views, also stop
transitions for the grand children. Detached children don't have a way
to continue animating anyway, since they have no stage view (thus frame
clock) to be driven by.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2716>
When a badly behaving ClutterActor implementation manages to invalidate
the allocation after the layout phase and before painting, we have no
idea where the actor should be painted without running the whole layout
machinery again.
For paint volumes in this case we pretend the actor covers the whole
stage and queue full-stage redraws. When updating stage-views, we're
also handling this case, but not in the most graceful way. Just like
with paint volumes, we should assume an actor without a valid allocation
is simply everywhere, so set priv->stage_views to all available stage
views in that case.
Related: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/6054
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2694>
Updating of the paint volume used for culling these days happens
during the finish-layout stage, not while painting. Also we have
geometry-based, not paint-based picking anymore.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1492>
Rename the `last_paint_volume` to `visible_paint_volume`: That avoids
confusion with the `had_effects_on_last_paint_volume_update` flag and
also makes it clear that this paint volume is the currently visible one.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1492>
Rename the paint_volume_valid flag to has_paint_volume in order to
better reflect what it's for.
The name "paint_volume_valid" implies that the paint volume can be
invalidated and thus sounds like it's involved with some kind of
caching. The flag that's actually involved with caching is
"needs_paint_volume_update", while "paint_volume_valid" is only meant to
store whether the actor has a paint volume to work with.
So rename paint_volume_valid to has_paint_volume to avoid confusion
about which flag is used for caching.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1492>
For clarity and for further improvements, introduce a separate function
to update the paint volume instead of doing that inside
_clutter_actor_get_paint_volume_mutable().
Also add a FIXME comment for a possible bug I noticed while working on
it.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1492>
These days it's possible to chain up into the default get_paint_volume()
implementation again, which renders
clutter_actor_get_default_paint_volume() unnecessary. So remove that
function and move clutter_actor_update_default_paint_volume() back into
real_get_paint_volume() where it belongs.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1492>
We traverse the whole screnegraph anyway these days in finish_layout(),
so no need for the whole "set the flag on parents even though we don't
need it" dance anymore.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2667>
If an actor is being unrealized or otherwise unparented, it's a good
indication that its grabs are now stale and possibly harmful. Ensure
these are dropped when the actor is unparented.
This is now an unlikely event, since there is code to also dismiss
grabs when a visible grabbed actor goes unmapped. But that may be
prevented from happening, or the ordering of circumstances allow a
grab to be created and an actor destroyed without going unmapped
first. This grab dismission on unmap stays as it matches the UI-level
expectatives that an actor must be visible to be grabbed.
Related: https://gitlab.gnome.org/GNOME/mutter/-/issues/2475
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2669>
The stage view list does not get updated when an actor gets hidden in
order to avoid unnecessary work, such as scale changes. However, we
still want `is_effectively_on_stage_view` to report `FALSE` in this
case.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2662>
Just like we did with the ::captured-event signal, add detail to the
::event signal too. At the first glance this might not seem necessary
since there are individual signals like scroll-event or touch-event that
get emitted at the same time, but these don't exist for touchpad gesture
events and others.
As an easy solution for that, just make it possible to use detail on the
event signal as we did with the caputured-event signal.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2431>
Somewhat long overdue... We've been supporting more than a single
pointer for quite a long time now, let's make sure things don't break if
two pointer devices enter the same ClutterActor: Count the number of
pointers an actor has instead of using a simple boolean value.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2348>
In certain edge cases it's currently possible that an actor never
gets a valid allocation and paint volume.
One such case is adding an unmapped, hidden child to an unmapped
cloned parent and then showing the child. This happens currently
e.g. if a Wayland subsurface is added to a already mapped window
while the user is in the overview.
Ensure relayouts in two more such cases.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2530>
The notification list in the GNOME Shell calendar popup triggers some
interesting interactions when closing a notification:
- Close button is clicked
- The notification animates to be hidden
- The next notification ends up hovered as a result of the animation
- The notification being hovered sets its close button as non-transparent
and reactive
- The pointer is now again over a close button
At this point the reactiveness change should trigger a repick, so that
the new notification's close button is picked, and future button presses
are directed to it, but we do not handle this situation.
To fix this, handle actors becoming reactive so that if the closest
reactive parent has a pointer, it will be repicked again just in case
the pointer is over the newly reactive actor.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2364
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2532>
`clutter_actor_iter_destroy` will try to match up the iterator's `age`
with that of the parent ("root") actor:
```
g_return_if_fail (ri->age == ri->root->priv->age);
```
In a simple actor graph that's completely reasonable but somewhere in the
more complex graph of gnome-shell the parent's `age` was skipping ahead
faster than that of the iterator. This could happen in theory if the
destroy indirectly leads to more children being destroyed than the
iterator has visited.
So there's no evidence of actual corruption, only the age check might
fail in a `clutter_actor_iter_destroy` loop because the age check itself
can't handle all possible valid scenarios.
Since our only mandate is to destroy all children, we can do that reliably
without an iterator and thus without assuming anything about the parent's
`age` counter.
Fixes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/4747
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2074>
ClutterColorState, that is a GObject. each ClutterActor would own
such an object, and it'd be set via a GObject property.
It would have an API to get the colorspace, whether the actor
content is in pq or not, and things like that.
if it is NULL, it will default to color state with sRGB colorspace.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2443>
I've overseen quite an important case in commit
98a5cb37d9159737f8f1af4196420db90bfcf879: Repicking only when actors get
destroyed is not enough, we actually need to repick when actors go
hidden/unmapped.
While we could also listen to notify::mapped just like we listen to
notify::reactive, it seems better to avoid using property notifications
here due to the usage of g_object_freeze/thaw_notify() in ClutterActor.
It can lead to the stage receiving a notify::mapped with mapped = true
for a pointer actor, which really shouldn't happen (just like
notify::reactive with reactive = true shouldn't happen).
Fixes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/5124
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2333>
