There's no compositing during direct scanout so the "render" time is zero.
Thus there is no need to implement triple buffering for direct scanouts.
Stick to double buffering and enjoy the lower latency.
Because the buffer queue may grow by an extra frame in triple buffering,
we need measurements exceeding one frame to indicate when and by how much
the scaling is necessary.
Chronologically they already overlap in time as presentation may
complete in the middle of the dispatch function, otherwise they are
contiguous in time. And most switch statements treated the two states
the same already so they're easy to merge into a single `DISPATCHED`
state.
Having fewer states now will make life easier when we add more states
later.
Error diffusion was introduced in 0555a5bbc1 for Nvidia where last
presentation time is always unknown (zero). Dispatch times would drift
apart always being a fraction of a frame late, and accumulated to cause
periodic frame skips. So error diffusion corrected that precisely and
avoided the skips.
That works great with double buffering but less great with triple
buffering. It's certainly still needed with triple buffering but
correcting for a lateness of many milliseconds isn't a good idea. That's
because a dispatch being that late is not due to main loop jitter but due
to Nvidia's swap buffers blocking when the queue is full. So scheduling
the next frame even earlier using last_dispatch_lateness_us would just
perpetuate the problem of swap buffers blocking for too long.
So now we lower the threshold of when error diffusion gets disabled. It's
still high enough to fix the original smoothness problem it was for, but
now low enough to detect Nvidia's occasionally blocking swaps and backs
off in that case.
Since the average duration of a blocking swap is half a frame interval
and we want to distinguish between that and sub-millisecond jitter, the
logical threshold is halfway again: refresh_interval_us/4.
While it was correct for double buffering, the test was wrong for
triple buffering and would lead to accidentally staying in triple
buffering for too long.
Fixes: 8f27ebf87e
This gives greater control to the callers on the place where a grab is being
activated, this may make a difference in the handling of crossing events
triggered through it, e.g. by having callers rely on having already obtained
a ClutterGrab prior to handling the resulting effects.
The "input only" grab has also been turned inactive by default, in order to
to have the ClutterGrab pointer available for checks at the MetaWaylandEventHandler
focus changing methods triggered through grab activation.
(cherry-picked from commit 8e5f3a1f83)
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3874>
When cloning an actor we were applying a global scale to it, based on
the size of the clone itself and of the cloned actor.
This implied that the transformed size of the clone was not the one that
was set, but it was taking taking in account the actor scaling too.
So in practice we were scaling it twice.
While this had no visual implications it indeed was causing troubles
when a ClutterClone was reactive because in such case only the scaled
area of the scaled clone was considered reactive.
Assume you had an actor of 100x100 pixels, scaling it to a clone of
50x50 pixels:
- The scale applied to the clone was 0.5
- The transformed size of the clone was: 25x25 pixels
- The clone was reactive only in that sub-area
To avoid this, never touch the clone transformation matrix, but only
transform it at paint time.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2959>
(cherry picked from commit 44c0c311ba)
If the presentation time isn't known, e.g. if the monitor is virtual and
the actual presentation happens far away, the presentation time we
actually received tends to be the time a frame was presented to the next
layer, meaning practically immediately after painting.
When scheduling another update after that, don't assume that if the next
calculated update is not the immediate next update, schedule an update
sooner, as that will in such cases always be true, meaning we ended up
busy looping with constant frame updates being scheduled.
Fix this by only triggering that logic if the last presentation time was
actually vsync:ed.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3803>
ClutterInputMethods content hint or purpose will be set again (even to the
same values) whenever a wayland client sends us a new content type/purpose.
Gtk appears to always set a content purpose on wl_text_input changes, so we
currently set and notify the "content-purpose" property on every change in a
gtk text field.
Since the OSK is gnome-shell listens to this property and re-generates its
entire layout when the content-purpose prop gets notified, this is currently
causing lag/freezes on every keypress in the OSK in gnome-shell.
So ensure to not notify these properties in case they're equal and set the
properties in the same way as we usually set them instead of going via
GObject.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3645>
Gestures are independent from each other when they are on different
actors and when they don't have a conflict over input with each other: For
example a gesture on one window and a gesture on another window will
recognize at the same time perfectly fine right now.
For those gestures (let's call them "independent gestures") we don't want
to control how the conflicting input should be handled, i.e. whether one
gesture wins over another or whether both can be recognizing using the
same touchpoint (e.g. zoom+rotate on the same actor). Instead we want
to control whether they are allowed to start while another one is running.
For now, make it impossible for two gestures to recognize globally at
the same time in all cases. This helps prevent subtle bugs and makes life
easier for users of the API. We can introduce API for fine grained control
over the behavior later.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2389>
With the next commit, we'll need a list of all gestures that currently are
active globally. Since actors and actions (and therefore also gestures) in
Clutter are bound to a stage, it makes sense for this list to exist on the
ClutterStage level.
The list itself is a simple GPtrArray (to allow for quick searches) that
doesn't reference the gestures and is not manipulated by the stage itself.
All manipulation of the array is left to ClutterGestures.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2389>
Quite often there are situations where multiple gestures try to
recognize, keeping track of the same set of points (for example an edge
drag gesture on the stage and a click gesture somewhere in the
scenegraph). Usually what's wanted here is that the first gesture to
move to RECOGNIZING wins over all other active gestures and "claims" the
point for itself.
We implement this by introducing a concept called "influencing". It
works by making all gestures operating on a shared set of points aware
of each other using ClutterAction->register_sequence().
ClutterGesture uses this vfunc to keep track of all other
ClutterGestures that are potentially conflicting, and keeps a list
(priv->cancel_on_recognizing) of those. As soon as the move to
RECOGNIZING happens, all gestures inside this list get moved to
CANCELLED.
To allow fine-grained control over this behavior, two APIs are
introduced:
1) on the implementation level (should_influence() and
should_be_influenced_by()): This is a vfunc that gets called as soon as
a potential conflict is detected. It's helpful when a specific gesture
always behaves the same towards another gesture, for example to make
sure a LongPress gesture never cancels a DragGesture.
2) on the gesture user level, clutter_gesture_can_not_cancel() is
introduced: This allows control for the user of a gesture to specify
that a specific instance of a gesture won't cancel another gesture.
Calling this twice so that both gestures can't cancel each other allows
for things like simultaneous recognition of a pinch-to-zoom and rotate
gesture.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2389>
Introduce ClutterGesture, a new ClutterAction subclass and the successor
of ClutterGestureAction that brings the necessary tools to handle
sequences of events and abstract touch and mouse gestures from those.
The big difference compared to ClutterGestureAction is that ClutterGesture
provides the implementation with point_added/moved/ended and
sequences_cancelled events and expects the implementation to move the
ClutterGesture through the ClutterGestureState state machine. This state
machine is then used internally by ClutterGesture to coordinate with other
gestures.
With the next commits, ClutterGesture will handle relationships between
conflicting gestures completely by itself, allowing the implementation or
the user to specify the details of the relationship between two gestures.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2389>
clutter_event_get_source() is still valid for the case of crossing events,
just like clutter_event_get_related(). The latter is not deprecated, so the
former shouldn't be either.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2389>
ClutterStage will unref an action in the middle of its own event handler in
case the action causes its own actor to be destroyed. In this case the
action would get freed underneath our feet. To avoid it, take a ref on the
action while calling its handle_event() vfunc, just as we do in
clutter_actor_event() while emitting an event to an actor.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2389>
Since commit e30eb78891 `ClutterFrameClock` assumes that a valid CPU time
implies timestamp query support, which is also checked in
`cogl_onscreen_egl_swap_buffers_with_damage()`.
Unconditionally setting the CPU time on direct scanout meant that the
compositing path would be stuck on the last (direct scanout optimized)
result on GL implementations without timestamp query support since.
be0aa2976e (clutter/frame-clock: Avoid rapidly toggling dynamic max render time)
Fix that by explicitly marking the gpu rendering duration as valid when
querying the GPU timestamps is supported and check for it ClutterFrameClock.
Fixes: 56580ea7c9 ("backends/native: Assume zero rendering time for direct scanout buffers")
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3655>
Currently, ClutterFrameClock uses g_source_set_ready_time() to determine
the usec timing of the next frame. That translates into a poll() with a
millisecond timeout if no trigger occurs to break the poll() out early.
To avoid spinning the CPU, GLib always rounds *up* to the next millisecond
value unless a timeout of 0 was provided by a GSource.
This means that timeouts for the ClutterFrameClock can easily skew beyond
their expected time as the precision is too coarse.
This applies the same concept as GNOME/glib!3949 but just for the
ClutterFrameClock. That may be more ideal than adding a timerfd for every
GMainContext, but we'll see if that lands upstream. I wanted to provide
this here because it could easily be cherry-picked in the mean time if
this is found to be useful.
From a timer stability perspective, this improves things from erratically
jumping between 100s and 1000s off of the expected awake time to single
or low double digits.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3636>
A new variable scheduling mode is introduced which allows lower
priority updates to be scheduled on a timeout which represents a lower
refresh rate, while allowing high priority updates to be scheduled to
occur as soon as possible.
This mode will be used by following commits to implement
synchronization of page flips to the update rate of specifc surface
actors.
High priorty updates are either scheduled to occur "now" if they
arrive at a rate which is lower than the maximum refresh rate, or
according to the measured maximum render time if they arrive at a
rate which meets or exceeds the maximum refresh rate. This approach
allows achieving low input latency in both scenarios.
Seperate handling for low priority updates is needed to avoid visible
stutter in the content of the surface that drives the refresh rate. An
example for a low priority update is cursor movement when the KMS
deadline timer is disabled.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1154>
This is conditionally toggled by grabs on the current key focus depending
on whether the current key focus actor would receive events according
to the grab or not. Which means it's no longer a reliable method for an
actor to know it does have focus, without asking the stage about it.
Avoid this check and ask the stage for the key focus, in order to make
key focus actors able to unset themselves despite the presence of grabs.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3629>
The min height reported by ClutterText when ellipsize and line-wrapping are
enabled was too small to fit the text.
The coordinates from `pango_layout_get_line_extents()` are baseline relative,
so the `y` coordinate means that the highest ascent would be `-y` above the
baseline and height gives the span between the ascent above the baseline and
the descent below it, so `logical_line_rect.y + logical_line_rect.height`
gives us the size of the descent. This is the wrong height to use for the
height of the actor.
The coordinates of the layout extents don't seems to be related to the baseline
and are just for offsets when rendering, that's probably how this bug got
initially introduced.
Therefore, the `y` coordinate from the layout is the correct offset to use,
even though, when looking at `pango_layout_get_extends_internal()`, it appears
that `y` is always set to 0.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3610>
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>
