Ensure the window is placed in coordinates, before maximizing, tiling or
minimizing it. This should make the window maximized/tiled on the right
(or correctmost) monitor given the stored coordinates.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4311>
Ensure that windows get restored either in maximized and unmaximized
state. And ensure that monitors being removed result in windows
snapping back to reachable positions.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4311>
We don't want triple buffering when the estimated maximum update time is
known and no larger than a refresh interval. In that case, regular frame
clock dispatch is scheduled after the previous frame is presented, so no
third buffer is necessary.
Allowing triple buffering anyway was problematic when frames are skipped
for reasons other than the frame update taking too long (e.g.
https://gitlab.gnome.org/GNOME/mutter/-/issues/3884):
1. First frame dispatches, targets display refresh cycle (DRC) n, but
skips
2. Second frame dispatches, targets DRC n+1
3. First frame is presented at DRC n+1
4. Second frame is presented at DRC n+2
Without triple buffering:
2. First frame is presented at DRC n+1
3. Second frame dispatches, targets DRC n+2
4. Second frame is presented at DRC n+2
The second frame is presented at DRC n+2 in both cases, but with triple
buffering it targeted n+1, i.e. its contents might not be consistent
with when it's presented.
It gets worse with triple buffering if the second frame also skips:
4. Second frame skips, is presented at DRC n+3
That's a discrepancy of 2 refresh cycles between the target and
effective presentation time, which might be noticeable as more severe
stutter.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4282>
With triple buffering, frame_clock->next_presentation_time_us
corresponds to a different frame in
clutter_frame_clock_notify_presented.
Also remove superfluous has_next_presentation_time field, any
target_presentation_time value > 0 is valid.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4282>
The superseded frame is always the oldest frame so it's the head of
the queue, not the tail. Aside from anything else, the call to
`meta_onscreen_native_notify_frame_complete` that follows *does* use
the head and not the tail.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4310>
`gdctl show` now prints "monitor preferences", which currently consists
of only the luminance setting.
`gdctl prefs` is introduced, where one can run e.g. `gdctl prefs
--monitor DP-1 --luminance 80.0` to set the output luminance of the
monitor connected to DP-1 to 80%.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4271>
This aims to allow configuring the output luminance currently used via
the color state shaders. It will replace the output luminance property
of the debug control API.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4271>
