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>
There do indeed seem to be places in our own code that trigger grabs on
actors before they are realized. It was not the intention to change the
practical preconditions for GNOME 43, so make it an even lower minimum
that every caller ought to match: That the actor is attached to the stage.
Further constraining of these preconditions will have to wait until
branching for new development.
Fixes: 9c79c7234 (clutter: Only allow grabs to be created on realized actors)
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2670>
The bare minimum that we can ask to an actor before creating a grab
on it is that it is realized (and thus, attached to the stage). Bail
out if that is not the case when creating a grab.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2669>
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>
The :input-purpose and :input-hints properties were added without
actually handling the get/set operations, whoops.
All code uses the (working) methods, so this only fixes expectations,
not an actual bug :-)
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2659>
If we have a window that match the size (i.e. will pass the "fits
framebuffer" low level check), that doesn't mean it matches the
position. For example, if we have two monitors 2K monitors, with two 2K
sized windows, one on monitor A, and one on monitor both monitor A and
B, overlapping both, if the latter window is above the former, it'll end
up bing scanned out on both if it ends up fitting all the other
requirements.
Fix this by checking that the paint box matches the stage view layout,
as that makes sure the actor we're painting isn't just partially on the
right view.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2387
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2624>
A few calculations and assignments are done unnecessarily when the
last next presentation time is invalid. This increases the cognitive
complexity of the function for no reason.
No change in behavior.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2486>
I don't see how this makes sense at all, ClutterClickAction really
shouldn't mess with BUTTON_RELEASE events that are not part of a
gesture.
So propagate those events instead of stopping them.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2552>
The source field was removed from ClutterEvent with commit
b644ea1bce because the preferred way of
getting the event actor is now to use the device/sequence actor from the
stage directly.
With crossing events it's not that easy though, as crossing events
explicitly have a source and related actor that doesn't have to be the
same actor as the device actor. Since we kept around the "related" field
there anyway, let's also introduce a "source" field in
ClutterCrossingEvent and return that actor when get_source() is called
on a crossing event.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2551>
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>
In some hardware configurations, presentation timestamps could be
missing from some page flip events, leading to a temporary loss of
vblank synchronization.
This occurs at least with AMD GPUs for atomic commits that only update
the cursor plane. [0]
In those cases, it's better to calculate the next update time
according to the last valid presentation timestamp instead of relying
on the dispatch lateness.
[0] https://gitlab.freedesktop.org/drm/amd/-/issues/2030
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2481>
When taking the scanout path we still want to clear the
redraw-clip from the stage-view in order to ensure we skip
frames in `handle_frame_clock_frame()` if no new redraw-clip
was recorded.
This was not done previously as the accumulated redraw-clip was
needed for the next repaint, likely under the assumption that
scheduling a scanout repeatedly would be computationally cost-free.
This assumption does not hold in a VRR world.
In order to archive both, an accumulated redraw-clip for the next
paint and frame-skipping during scanout, introduce new API to defer
and accumulate redraw-clips until the next repaint.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2480>
Similar to the clutter commits
- Drop all the private structs documentations
- Make use of gi-docgen items linking as much as possible
- Use markdown formatting for code snippets
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2441>
This can happen with the native backend if the previous frame clock
dispatch didn't result in any KMS update, e.g. because it was triggered
by an input event, but the HW cursor didn't need updating on the stage
view. (This is likely to happen on some out of multiple stage views,
but might be possible even with a single stage view if the cursor isn't
visible)
We would previously delay next_presentation_time_us by one refresh
interval in this case, which could result in spuriously leaving one
refresh cycle unused.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2498>
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>
The function that currently invalidates pointers over an specific actor
also asserts for the situations where this invalidation makes sense to
happen (i.e. the actor became unmapped, or non-reactive).
We want to have a function that is more forgiving, and that doesn't
enforce any guarantees about the pointer focus actually changing.
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>
There are no 'features' left, the last one, GLSL shader support, was
moved to Cogl.
This also move the Cogl context creation to a more sensible place, as it
was hidden away in the feature initialization.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2015>
The Cogl feature was removed a while back, while Clutter just hard coded
it to TRUE. Lets remove the confusion that GLSL isn't supported and just
remove the (dead) fallback paths.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2015>
Cleanup all the boilerplate, and port the function to use the auto
generated private helper. Remove the manual autocleanup declaration
since this is now done in the clutter-image.h header.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2355>
A slightly annoying "feature" of Clutters debug messages is that it also
logs the filename and line of the current debug message. If you don't
have an ultrawide monitor, this can be very annoying and cause lots of
linebreaks in the debug logs.
So remove that debugging feature and no longer log the filename and
line number with debugging messages.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2378>
This is a signal that will be emitted between the 'before-update' and
'before-paint'. It can be used to handle things when you know whether
there is an update, and you know whether a paint or not will happen, by
looking at the current damage.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2393>
Mutters event filter can prevent events from getting processed by
Clutter, this can also happen for TOUCH_END/CANCEL events. Processing
these events in Clutter is crucial for proper tracking of touch
sequences though, that's because Clutter adds a PointerDeviceEntry to
the stage on a TOUCH_BEGIN *before* going through the event filter, but
removes that entry on a TOUCH_END *after* going through the filter. So
Clutter really needs to see those TOUCH_END events, or else there will
be a stale PointerDeviceEntry on the ClutterStage.
Make sure those TOUCH_END/CANCEL events always get seen by Clutter by
removing the device entry immediately when those get filtered out.
Because there might still be events belonging to this sequence in the
event queue of the stage, we need to flush the queue before removing the
entry, too.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2350>
