Previously if we had no measurements then `compute_max_render_time_us`
would pessimise its answer to ensure triple buffering could be reached:
```
if (frame_clock->state == CLUTTER_FRAME_CLOCK_STATE_DISPATCHED_ONE)
ret += refresh_interval_us;
```
But that also meant entering triple buffering even when not required.
Now we make `compute_max_render_time_us` more honest and return failure
if the answer isn't known (or is disabled). This in turn allows us to
optimize `calculate_next_update_time_us` for this special case, ensuring
triple buffering can be used, but isn't blindly always used.
This makes a visible difference to the latency when dragging windows in
Xorg, but will also help Wayland sessions on platforms lacking
TIMESTAMP_QUERY such as Raspberry Pi.
(cherry picked from commit 7852451a9e93f5116fa853350020a318d31cb710)
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1441>
Signed-off-by: Mingi Sung <sungmg@saltyming.net>
But only if we've ever got actual swap measurements
(COGL_FEATURE_ID_TIMESTAMP_QUERY). If it's supported then we now drop to
double buffering and get optimal latency on a burst of cursor-only
updates.
Closes: https://launchpad.net/bugs/2023363
(cherry picked from commit b2c16a63d2127faa0ebd811fab65c8be97a74469)
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1441>
Signed-off-by: Mingi Sung <sungmg@saltyming.net>
1. When direct scanout is attempted
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.
2. If disabled by environment variable MUTTER_DEBUG_TRIPLE_BUFFERING
With possible values {never, auto, always} where auto is the default.
3. When VRR is in use
VRR calls `clutter_frame_clock_schedule_update_now` which would keep
the buffer queue full, which in turn prevented direct scanout mode.
Because OnscreenNative currently only supports direct scanout with
double buffering.
We now break that feedback loop by preventing triple buffering from
being scheduled when the frame clock mode becomes variable. Long term
this could also be solved by supporting triple buffering in direct
scanout mode. But whether or not that would be desirable given the
latency penalty remains to be seen.
(cherry picked from commit 280f7f6b26cd3e7a82706d1d001419295ea15d8b)
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1441>
Signed-off-by: Mingi Sung <sungmg@saltyming.net>
This will allow the backend to provide performance hints to the frame
clock in future.
(cherry picked from commit 9b5f91b086b6a16c548626fed0e33f776cf3f030)
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1441>
Signed-off-by: Mingi Sung <sungmg@saltyming.net>
This replaces the DISPATCHED state with four new states that are possible
with triple buffering:
DISPATCHED_ONE: Double buffering
DISPATCHED_ONE_AND_SCHEDULED: Scheduled switch to triple buffering
DISPATCHED_ONE_AND_SCHEDULED_NOW: Scheduled switch to triple buffering
DISPATCHED_TWO: Triple buffering
It's four states simply because you now have two booleans that are no
longer mutually exclusive: DISPATCHED and SCHEDULED.
(cherry picked from commit e323bc74b9abb3f694637848421237cf163594bc)
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1441>
Signed-off-by: Mingi Sung <sungmg@saltyming.net>
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.
(cherry picked from commit a83535e24aecb9148f334b3d5cef9537709dc52a)
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1441>
Signed-off-by: Mingi Sung <sungmg@saltyming.net>
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.
(cherry picked from commit 4304155aa2ef681814641f3ccb5e60c06347178c)
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1441>
Signed-off-by: Mingi Sung <sungmg@saltyming.net>
While in double buffering we only care about one previous presentation,
triple buffering will sometimes need to refer to the presentation from
two dispatches prior. So it might help to separate those frame stats
more clearly. This way each frame's dispatch and presentation times are
stored more cohesively such as to not be overwritten during overlapping
frame lifetimes.
Having two types of frame reference (dispatch and presentation) moving
at difference speeds meant that they could not be stored in a ring. Not
all dispatches become presentations and so storing them in a ring would
necessitate very complex conflict avoidance. Instead, a simple reference
counting model was used.
(cherry picked from commit 817a951b246b64fd1c4148e486d24017f71fc4c4)
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3961>
Signed-off-by: Mingi Sung <sungmg@saltyming.net>
So that we maintain a perfectly balanced number of callbacks:
dispatch == notify_ready + notify_presented
Otherwise you can't put any useful logic inside notify_ready and be sure
you're handling all the empty frames.
(cherry picked from commit 85f0f4e227b7f6896fc9fe6d6b9da4d568d2a9e7)
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3961>
Signed-off-by: Mingi Sung <sungmg@saltyming.net>
Quoting Ebassi https://www.bassi.io/articles/2023/02/20/bindable-api-2023/:
Whenever you’re describing a function that takes a callback, you
should always annotate the callback argument with the argument that
contains the user data using the (closure argument) annotation
You should not annotate the data argument with a unary (closure).
The unary (closure) is meant to be used when annotating the callback
type
Recently gobject-introspection became a bit more strict with this and
that generated some warnings:
Warning: Cogl: invalid "closure" annotation: only valid on callback
parameters
This commit fix all the closure annotations.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4058>
(cherry picked from commit 077eb80a8d)
We only need to wake up the other side of the GAsyncQueue if we transition
from 0 to 1 item in the queue. Otherwise, we can be certain that the other
side has received a wakeup and will eventually flush the queue.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4007>
This uses the luminance levels of the color states to anchor the white
of content instead of hard-coding the levels.
This also starts using uniforms for parts of the mapping which means we
don't have to generate and compile a shader when the luminance levels
change.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3953>
They represent the minimum and maximum luminance levels of the primary
color volume and the reference luminance level (reference white, SDR
white, ...) in the reference viewing environment.
They help anchoring the white level, optionally help with preserving the
dynamic range and help with adjusting from a "dark" to a "bright"
viewing environment.
The values have defaults which depend on the transfer characteristics.
This reflects the wayland color management protocol.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3953>
Actions might get detached sometime during event processing,
at a time that the stage did already prepare an emission chain
holding references to the actions and actors that need to handle
events. This means actions might become detached, but still handle
the incoming event, or possible crossing events generated in-place
when the actor becomes unparented.
Avoid this situation, by skipping event handling on actions that
went detached, we will just instruct to continue event processing.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3988>
Instead, get it from the context. See next commit
For ClutterText, we had to switch to using constructed
as the ClutterContext will be set for the ClutterActor in the
constructor phase
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3977>
See previous commit log on the effects of this.
This means the deadline evasion needs to be added in both cases in
clutter_frame_clock_notify_presented.
v2:
* Use meta_kms_update_set_sync_fd. (Jonas Ådahl)
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3958>
As a writable property, nothing sets it in both Mutter/GNOME Shell
making it a dead-code. As we will be moving pango related bits to
gnome-shell, remove this one already
Removes pango-ft2 dependency
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3969>
As GNOME Shell always sets that to FALSE anyways
This does not drop the separate caching whether the mipmapping is
disabled or not, in case shell wants to make use of that in the future
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3962>
And stop passing in the color states from the RendererNative. We also
keep the color states updated by listening for changes in the color
device.
The RendererX11Cm has a single view and no mapping to a specific color
device, so we handle the absense of a color device as well and rely on
ClutterStageView to have the default color states.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3930>
