Users of Clutter grabs may listen for notify::revoked changes in
order to know that their grab is no longer in charge of event
propagation, without the use of crossing events.
Since a ClutterGrab may stay in the stack and regain effects,
this notification also happens the other way around.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3420>
The MetaWaylandPointer used to put this together through
MetaCursorTracker cursor visibility, and ClutterSeat-level
inhibition API, applying the pointer focus changes due to
visibility logically to Wayland clients.
In order to make this work over all Clutter widgetry
instead of just Wayland clients, make the ClutterSeat-level
inhibition API control this feature at the ClutterStage picking
level, and leave/enter the seat pointer as appropriate.
By default, the seat pointer has (un)focus inhibited. The
MetaCursorTracker has been made another player in unfocus
inhibition, simply asking for the pointer to get its focus
while the cursor is visible.
This in practice means that picking code may return a NULL
actor, some asserts and preconditions had to be changed to
handle this, plus some test code slightly.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3420>
The new CLUTTER_FRAME_CLOCK_STATE_SCHEDULED_NOW state is almost
identical to CLUTTER_FRAME_CLOCK_STATE_SCHEDULED, with one important
difference being that it avoids updates from being repeatedly
rescheduled "now" when multiple calls to
clutter_frame_clock_schedule_update_now() are done before the source
is actually dispatched.
Such repeated calls to schedule an update "now" may actually postpone
the dispatch if the CPU is very busy and the source dispatch is
delayed, defeating the purpose of scheduling a frame "now".
It also allows rescheduling "now" when the frame clock is uninhibited
after being inhibited while an update was scheduled "now". This may
be important in cases where the frame clock is inhibited for very
short periods in which it would otherwise lose the state of being
scheduled "now".
Scenarios such as this would become more common with the introduction
of variable refresh rate since it makes scheduling "now" a commonplace
occurrence.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3561>
Currently, the paint-volumes/redraws debug flags displays the actor
debug
names on top of the paint volume making it very unusable. Especially
that you can easily get the relevant actor from looking glass.
The motivation is to reduce the usage of pango (through the text node)
in order to possibly move all the fonts bits to gnome shell
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3571>
This removes an incorrect implicit assumption in
calculate_next_update_time_us() that a frame may only be scheduled
once in the duration of a refresh cycle. It accomplishes this by
setting last_next_presentation_time_us on presentation feedback
instead of calculating it every time an update is scheduled.
Specifically, it corrects the intended scheduling logic in scenarios
like the following, when all of the below occur in the context of a
single refresh cycle:
1. Frame update (1) is scheduled normally, and
"is_next_presentation_time_valid" is set to TRUE
2. Frame update (1) is dispatched but ends up being "empty" (no
presentation necessary)
3. Frame update (2) is scheduled "now" and
"is_next_presentation_time_valid" is set to FALSE
4. Frame update (2) is dispatched but ends up being "empty" (no
presentation necessary)
5. Frame update (3) is scheduled normally, and since
"is_next_presentation_time_valid" is set to FALSE, the
"early presented event" logic is unintentionally skipped in
calculate_next_update_time_us().
6. Frame update (3) is dispatched and ends up being a "non-empty"
update, but its update time was calculated incorrectly because
some logic was skipped.
Scenarios such as this would become more common with the introduction
of variable refresh rate since it makes scheduling "now" a commonplace
occurrence.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3560>
Calculate the frame deadline in ClutterFrameClock's
calculate_next_update_time_us() rather than in MetaWaylandCompositor's
on_after_update().
The specifics of the deadline calculation for a given frame should be
implementation detail of the frame clock and and remain internal to
allow extensibility.
This extensibility is specifically useful for scenarios where a
different deadline calculation is needed due to alternative frame
scheduling logic, such as for VRR.
No change in behavior.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3521>
In various public APIs, Clutter used to return a PangoDirection
while we have a text direction enum defined in Clutter.
This allows us to drop pango dependency from meta making it specific
to cogl-pango & clutter
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3531>
Since StDrawingArea in gnome-shell is the only user of ClutterCanvas,
it is possible to move ClutterCanvas completely out of Mutter to
gnome-shell. This allows to remove another Cairo dependency from
Mutter.
This patch removes ClutterCanvas code from Mutter.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3470>
Since StDrawingArea in gnome-shell is the only user of ClutterCanvas,
it is possible to move ClutterCanvas completely out of Mutter to
gnome-shell. This allows to remove another Cairo dependency from
Mutter.
This patch makes clutter_actor_create_texture_paint_node() function
public to be used by StDrawingArea in gnome-shell that replaces
ClutterCanvas.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3507>
On one hand this avoids crashes early after startup if the very first
pointer event is a scroll event, since the stage did not pick an actor
for the pointer device yet.
On the other hand, scroll events have some likelihood to change the
actor under the pointer even though it doesn't move. We still want to
cross towards the new actor under the pointer ASAP, without waiting
for later events.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3112
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3517>
The slightly different styles in the different build files make it
harder to reason about or share c_args.
This notably ensures we never set any extra c_args for plain builds and
fixes the cc.get_supported_arguments() check in Cogl, Clutter and Mtk.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3333>
clutter_actor_get_transformed_position() would write the uninitialized
values of v2 when clutter_actor_apply_transform_to_point() fails in
_clutter_actor_fully_transform_vertices() because the actor has not been
added to the stage yet.
When called from JS this would overwrite the zero initialized values
passed in from gjs. If the uninitialized values now happen to correspond
to one of the NaN float values used by mozjs to represent a pointer
type, this would lead to seemingly random crashes in mozjs code later
on.
Avoid this by using _clutter_actor_fully_transform_vertices() directly,
which allows us to check if it failed.
Related: https://gitlab.gnome.org/GNOME/gnome-shell-extensions/-/issues/469
Related: https://gitlab.gnome.org/GNOME/gjs/-/issues/591
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3453>
Although they're in the same units, `radius` is easier to understand than
`sigma` and makes the public API independent of the blur algorithm used
behind the scenes. We now only keep the `sigma` terminology where the
implementation is Gaussian-specific.
The assumption that `sigma = radius / 2.0` is actually not new here. We
just move it from `_st_create_shadow_pipeline` (gnome-shell!1905) into
`clutter_blur_new`.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1908>
Some actors have a well-defined layout manager other than FixedLayout.
If they do, we can handle the layout manager creation at the
ClutterActor instantiation, like GTK does for widget layout managers.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3445>
