Do not include it at header side as it is not part of the installed headers.
Only keep it in cogl-gl-headers.h as it is a private header.
Add it to all the source files that depend on it.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3593>
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>
