delta/mutter.git/src/compositor, branch document-button-values

later: Handle gracefully calls with unset display

2021-03-13T15:12:36+00:00

This can happen when the display has been already closed, in such case
we should not crash but warn about the error and return early.

Part-of:

plugins/default: Initialize background color in a predictable manner

2021-03-12T15:09:45+00:00

The order of which function argument expressions are executed is
undefined, so don't rely on this for setting the background colors, as
it results in different colors on different architectures.

For example, it has been observed that the order of execution is
reversed comparing x86_64 and aarch64, making these two architectures
having different background color.

Fix this confusion, and also reproduceability in future reference tests,
by making the order of execution predictable.

Part-of:

background-content: Optimize rounded clipping shader a bit

2021-03-11T21:59:07+00:00

We're using the gtk4 shader for rounded rect clipping here, and gtk just
introduced a small optimization to make this shader a bit faster, so
let's do the same.

See https://gitlab.gnome.org/GNOME/gtk/-/commit/57e354c297e1703079c2bc6fb51211b24d884ac3

Part-of:

window-actor/x11: Queue full actor redraw when redraw queued

2021-03-09T17:42:58+00:00

With frame timings, we might end up in a situation where a frame drawn
is expected, but no damage was posted. Up until now, mutter handled
this, if the window wasn't completely hidden, by posting a 1x1 pixel
damage region. The problem with this is that we now are a bit more
aggressive optimizing away no-op redraws, meaning we still might end up
not drawing, making things get stuck.

Fix this by doing a full actor redraw, as that is the only reliable way
to both a new frame being drawn, as well as the actor in question itself
getting redrawn.

Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1516
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3369
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1471
Part-of:

compositor/x11: Notify the sync ring about frames on updates

2021-03-09T17:42:58+00:00

The sync ring has an API about "frames", where it is notified about
the end of frames. However, its "insert wait" call is done before
updates, meaning that some "insert waits" will never see the "after
frame" if there was no frame drawn. This will cause mismatching in the
frame counting, causing freezes in the synchronization until something
else triggers an actual frame, effectively "unfreezing" the sync ring.

Fix this by not only notifying the sync ring about frames when there
were actual frames drawn, but also on plain updates which didn't result
in a drawn frame.

Related: https://gitlab.gnome.org/GNOME/mutter/-/issues/1516
Part-of:

cogl: Make presentation time always MONOTONIC

2021-03-08T09:48:11+00:00

This concerns only the cases when the presentation timestamp is received
directly from the device (from KMS or from GLX). In the majority of
cases this timestamp is already MONOTONIC. When it isn't, after this
commit, the current value of the MONOTONIC clock is sampled instead.

The alternative is to store the clock id alongside the timestamp, with
possible values of MONOTONIC, REALTIME (from KMS) and GETTIMEOFDAY (from
GLX; this might be the same as REALTIME, I'm not sure), and then
"convert" the timestamp to MONOTONIC when needed. An example of such a
conversion was done in compositor.c (removed in this commit). It would
also be needed for the presentation-time Wayland protocol. However, it
seems that the vast majority of up-to-date systems are using MONOTONIC
anyway, making this effort not justified.

Part-of:

background-content: Fix pipeline cache size

2021-02-24T15:59:58+00:00

The cache had the size 9, which was "big enough" in the past, but when
more ways pipelines could be constructed, the size was not enough. The
need to increase the cache size was hard to spot though, since adding
pipeline flag didn't give any hints about the cache being directly tied
to these flag values.

So, when enough flag bits were set when attempting to retrieve and put a
pipeline in the cache, it'd instead overwrite some arbitrary stack
memory, which would sooner or later result in a memory corruption
induced crash. Valgrind could not detect this particular memory
corruption, as it messed up stack memory, not e.g. freed heap memory, so
it instead got confused and thought plain stack values were unreadable.

Fix these two issues by making the cache size the combination of all
pipeline flags + 1, so that we can safely put any flag combination in
the cache.

Part-of:

src: Stop using GSlice

2021-02-22T12:52:27+00:00

It has been inofficially deprecated for years, is known to cause issues
with valgrind and potentially hides memory corruption.
Lets stop using it.

Part-of:

display: Don't add MetaDisplay argument to grab-op-* signals twice

2021-02-19T13:52:22+00:00

GObject signals pass the emitting GObject as the first argument to
signal handler callbacks. When refactoring the grab-op-begin/end signals
to remove MetaScreen with commit 1d5e37050df2b8e1db8b5ea301ee0162d77d4b74,
the "screen" argument was replaced with a "display" argument instead of
being removed completely. This made us call the signal handlers with two
identical MetaDisplay arguments, which is very confusing and actually
wasn't handled in a grab-op-begin handler in gnome-shell.

So fix this by not adding the MetaDisplay as an argument to those
signals, GObject will take care of that for us.

Part-of:

background-content: Add support for rounded clipping when drawing

2021-02-18T20:26:42+00:00

We're going to round the workspace backgrounds in the new overview for
gnome-shell 40.

So far corner-rounding was only possible for StWidgets because the
rounded clipping was done using cairo drawing. We now need rounded
clipping for ClutterActors too because backgrounds are drawn using
ClutterActors (or more specifically a ClutterContent). To implement
that, first a ClutterOffscreenEffect subclass together with a fragment
shader from GSK (see gskSetOutputColor() [1] in the GSK GL renderer
code) was investigated, and while that was generic and worked quite
well, it was extremely slow for the case of drawing wallpapers because
of all the FBOs that had to be allocated.

This is the new, more performant approach: Use the same fragment shader,
but perform the rounded clipping right in MetaBackgroundContent while
we're painting the wallpaper. This has almost no performance impact,
with the downside of not being a generic solution.

To allow for rounded clipping not only at the edges of the wallpaper,
but using any given bounding rectangle, the API exposes not only the
radius, but also a bounding rect.

[1] https://gitlab.gnome.org/GNOME/gtk/-/blob/master/gsk/resources/glsl/preamble.fs.glsl

Part-of: