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: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1484>
KMS and GLX device timestamps have microsecond precision, and whenever
we sample the time ourselves it's not the real presentation time anyway,
so nanosecond precision for that case is unnecessary.
The presentation timestamp in ClutterFrameInfo is in microseconds, too,
so this commit makes them have the same precision.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1484>
A flag indicating whether the presentation timestamp was provided by the
display hardware (rather than sampled in user space).
It will be used for the presentation-time Wayland protocol.
This is definitely the case for page_flip_handler(), and I'm assuming
this is also the case for the two instances in the GLX code.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1484>
d42f1873fc introduced a semi circular
reference between the CoglFramebuffer, and CoglJournal, where
CoglJournal would keep a reference on the CoglFramebuffer when there
were any entries in the journal log.
To avoid risking leaking these objects indefinitely, when freeing
objects without doing anything that triggered a flush, CoglFramebuffer
had a "filter" on cogl_object_unref() calls, which knew
about under what conditions CoglJournal had a reference to it. When it
could detect that there were only the journal itself holding such a
reference, it'd flush the journal, effectively releasing the reference
the journal held, thus freeing itself, as well as the journal.
When CoglFramebuffer was ported to be implemented using GObject instead
of CoglObject, this "filter" was missed, causing not only awkward but
infrequent leaks, but also situations where we'd flush journals when
only the journal itself held the last reference to the framebuffer,
meaning the journal would free the framebuffer, thus itself, in the
middle of flushing, causing memory corruption and crashes.
A way to detect this, by asserting on CoglObject reference count during
flush, is by adding the `g_assert()` as described below, which will
assert instead cause memory corruption.
void
_cogl_journal_flush (CoglJournal *journal
{
...
_cogl_journal_discard (journal);
+ g_assert (journal->_parent.ref_count > 0);
...
}
Fix this by making CoglFramebuffer the owner of the journal, which it
already was, and remove any circle referencing that was there before, as
it is not needed given that the CoglFramebuffer pointer is guaranteed to
be valid for the lifetime of CoglJournal as the framebuffer is the owner
of the journal.
However, to not miss flushing before tearing down, which is important as
this flushes painting calls to the driver that is important for e.g.
using the result of those journal entries, flush the journal the first
time cogl_framebuffer_dispose() is called, before doing anything else.
This also adds a test case. Without having broken the circular
reference, the test would fail on g_assert_null (offscreen), as it would
have been "leaked" at this point, but the actual memory corruption would
be a result of the `cogl_texture_get_data()` call, which flushes the
framebuffer, and causes the 'mid-flush' destruction of the journal
described above. Note that the texture keeps track of dependent
framebuffers, but it does not hold any references to them.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1474
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1735>
It's currently only handled by a surface backend framebuffer (assuming
the right GLX extensions are available). While it's theoretically
possible to do the same with the offcreen by having multiple textures,
it's not supported, so leave the FBO variant with a single warning if we
end up there.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1514>
The object was still pretending to be CoglFramebuffer itself, by using
naming and calling conventions making it seem like that. Fix that by
passing around the driver instead of the framebuffer.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1514>
Mutter needs to fetch the X11 Window ID from the onscreen and did that
by using an X11 specific API on the CoglOnscreen, where the X11 type was
"expanded" (Window -> uint32_t). Change this by introducing an interface
called CoglX11Onscreen, implemented by both the Xlib and GLX onscreen
implementations, that keeps the right type (Window), while avoiding X11
specific API for CoglOnscreen.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1514>
Mutter didn't use the APIs for resizeability of CoglOnscreens but
managed the size itself. For the native backend we don't ever resize
onscreens. Thus, remove this unused functionality.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1514>
The framebuffer driver was lazilly initialized on demand in some cases
(onscreen), and up front other (offscreen). Replace this with a more
predictable up front initialization, done at framebuffer allocation.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1514>
The CoglGLFramebuffer (not CoglGlFramebuffer) is a private struct for
keeping track of the framebuffer object. To avoid confusing with
CoglGlFramebuffer, rename it CoglGlFbo.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1514>
This way we can have separate types per modes of operation (e.g. if it's
backed by an EGLSurface or single texture), instead of being dependent
on a certain type (onscreen vs offscreen).
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1514>
Instead of calling "init_onscreen()" on two different separate vtables
from the allocate() funtion, just have the CoglOnscreen sub types
themself implement allocate() and initialize in there.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1514>
Thins means that e.g. MetaOnscreenNative now inherits CoglOnscreenEgl,
which inherits CoglOnscreen which inherits CoglFramebuffer, all being
the same GObject instance.
This makes it necessary to the one creating the onscreen to know what it
wants to create. For the X11 backend, the type of renderer (Xlib EGL or
GLX) determines the type, and for the native backend, it's currently
always MetaOnscreenNative.
The "winsys" vfunc entries related to onscreens hasn't been moved yet,
that will come later.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1514>
The mutter naming convention for types and their instance variables is:
Type name:
[Namespace][BaseName][SubType]
Instance name:
[base_name]_[sub_type]
This means that e.g. CoglOnscreenGLX is renamed CoglOnscreenGlx, and
glx_onscreen is renamed onscreen_glx. This is in preparation for
GObjectification.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1514>
The GLX winsys code had split up the GLX onscreen implementation into an
Xlib part (with a struct name confusingly enough identical to that of
the onscreen in the actual Xlib winsys). To remove some confusion,
combine the two.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1514>
This makes it possible to post a symbolic page flip and frame callback,
meant to be used by immediate symbolic page flip reply when emulating
cursor plane changes using legacy drmMode* functions.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
We will soon need to use CoglOnscreen frame events communicate cursor
plane changes; this means we need to have a way to queue them without
going through any of the current APIs that can do so, i.e. the swap
buffer functions and direct scanout.
Add a function that just adds a frame info to the queue. The one who
adds it is responsible for emitting it too.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
Don't mode set each CRTC in separate KMS updates, as reconfiguring one
CRTC might cause other CRTCs to be implicitly reset thus as well,
causing KMS return EBUSY if using atomic modesetting.
Prepare for this by compositing each CRTC first including adding steps
to the KMS update, but wait until all views has rendered at least once
before posting the initial update. After this each CRTC is posted
separately.
Using EGLStreams instead of normal page flipping seems to fail when
doing this though, so handle that the old way for the EGLStream case,
i.e. eglSwapBuffers() -> mode set with dumb buffer -> eglStream
"acquire" (resulting in page flip under the hood).
For this we also introduce a new error code so that we don't use client
buffers when doing mode sets, which could accidentally configure the
CRTC in a way that is incompatible with the primary plane buffers.
Do the same also when we're in power save mode, to only have one special
case path for this scenario in the regular swap-buffer path.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
This argument is intended to be used by clutter to be able to
communicate with the onscreen backend, that happens to be the native
backend. It will be used to pass a ClutterFrame pointer, where the
result of page flips, mode sets etc can be communicated whenever it is
available.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
Because the framebuffer itself might be backed by a texture, which might
have mipmapping enabled. If so then rendering to the framebuffer will make
those mipmaps out of date.
Technically we are flagging the framebuffer's mipmaps as dirty *before*
they are, because the journal hasn't been flushed yet. But we need to do
it early because ideally the next flush will both write the offscreen
framebuffer contents and then read them for use in rendering to an onscreen
framebuffer. And the `mipmaps_dirty` flag needs to be set before the read,
so therefore we need to do it before the next journal flush.
Fixes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3146
where the offscreen framebuffer in question is meta-background's
`monitor->fbo`.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1664>
If texture allocation failed for a sliced 2D texture, the alloc()
function would free the slices immediately, but not clear the pointer to
the slices array. When the code attempting to allocate the texture then
freed the texture object, the cleanup functions tried to free the slices
array again, since it wasn't NULL.
Fix this by clearing the slices array after freeing it.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1580
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1648>
This allows profilers to trace the callers of whatever is spending the
most time on the GPU, and to measure render times more accurately.
Previously such information was hidden as it completed in the
background (asynchronously) after we call swap buffers.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1327>
The "paint" signal of ClutterActor is deprecated and will be removed. We
have a good replacement to get notified about stage paints nowadays,
that is "after-paint" on ClutterStage, so switch to that signal where it
makes sense.
I didn't bother to update the few tests (namely Clutters
conform/texture-fbo.c, conform/text-cache.c,
interactive/test-cogl-multitexture.c and Cogls
conform/test-multitexture.c, conform/test-texture-mipmaps.c) where it's
harder to replace the signal since we don't build those anyway.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1522
Instead of our own implementation that upscales, then downscales back,
use graphene_matrix_inverse() directly. This is possible after switching
to a z-near value that doesn't have problems with float precision.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1489
A first step towards abandoning the CoglObject type system: convert
CoglFramebuffer, CoglOffscreen and CoglOnscreen into GObjects.
CoglFramebuffer is turned into an abstract GObject, while the two others
are currently final. The "winsys" and "platform" are still sprinkled
'void *' in the the non-abstract type instances however.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1496
The first argument is the framebuffer operated on, so in order to stay
consistest, rename 'src' to 'framebuffer'. The second is the
destination. The destination is commonly referred to as 'dst' elsewhere,
so rename 'dest' to 'dst'.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1496
This one is a bit tricky. The tl;dr; is that switching from right-hand
multiplication to left-hand multiplication required applying the stack
from left to root. This actually allowed simplifying the code a bit,
since CoglMatrixEntry only stores a pointer to its parent, and that's
all we need to know for left-hand multiplication.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1439
CoglMatrix already is a typedef to graphene_matrix_t. This commit
simply drops the CoglMatrix type, and align parameters. There is
no functional change here, it's simply a find-and-replace commit.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1439
Ideally, we would use Graphene to do that, however as of now Graphene
lacks these APIs so we still need these helpers. Since we're preparing
to get rid of CoglMatrix, move them to a separate file, and rename them
with the 'cogl_graphene' prefix.
Since I'm already touching the world with this change, I'm also renaming
cogl_matrix_transform_point() to cogl_graphene_matrix_project_point(),
as per XXX comment, to make it consistent with the transform/projection
semantics in place.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1439
Given that CoglMatrix is simply a typedef to graphene_matrix_t, we can
remove all the GType machinery and reuse Graphene's.
Also remove the clutter-cogl helper, and cogl_matrix_to_graphene_matrix()
which is now unused.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1439
After the previous commit, the only field in the CoglMatrix structure is
a graphene_matrix_t. That means that CoglMatrix is effectively a graphene
matrix now, and the CoglMatrix struct isn't that much useful anymore.
Remove the CoglMatrix structure and make the CoglMatrix type a typedef to
graphene_matrix_t.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1439
Remove the cached inverse, and dirty flags, and typedef CoglMatrix to
graphene_matrix_t itself. I preverved the type for this commit to help
reducing the commit size, next commits will remove the CoglMatrix type.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1439
CoglMatrix doesn't have a 1:1 mapping of graphene functions, and
sometimes it's just not worth adding wrappers over it. It is easier
to expose the internal graphene_matrix_t and let callers use it
directly.
Add new cogl_matrix_get_graphene_matrix() helper function, and
simplify Clutter's matrix progress function.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1439
Instead of listing all matrix cells as floats, and the inverse
as a 16-length float array, use graphene_matrix_t in the structure
itself.
With this commit, all from/to CoglMatrix conversions are gone. It
is also not possible to initialize a CoglMatrix using the macro
anymore.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1439
Rename cogl_matrix_get_array() to cogl_matrix_to_float(), and
make it copy the floats to an out argument instead of returning
a pointer to the casted CoglMatrix struct.
The naming change is specifically made to match graphene's,
and ease the transition.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1439
Internally, a graphene_matrix_t representing the same transform that
of a CoglMatrix is the same matrix but transposed, so in order to get
the same element given a column and row for a matrix as if it would
be located in Cogl, it is necessary to swap the row and column when
retrieving it from the graphene matrix.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1439
Turns out inverting a matrix was the largest chunk of the CoglMatrix
code. By switching to Graphene, a lot of it can go away. The inverse
is still cached in the CoglMatrix struct itself, to preserve the
optimization.
However, switching to graphene_matrix_t to calculate the inverse has
a challenge: float precision. We had to work around it here, and it
needs an explanation.
The way to detect whether a matrix is invertible or not (i.e.
whether it's not a "singular" matrix, or not) is by checking
if the determinant equals 0. So far, so good.
Both graphene_matrix_t and CoglMatrix use single-precision
floats to store their 4x4 matrices. Graphene uses vectorized
operations to optimize determinant calculation, while Cogl
tries to keep track of the matrix type and has special-purpose
determinant functions for different matrix types (the most
common one being a 3D matrix).
Cogl, however, has a fundamentally flawed check for whether
the matrix is invertible or not. Have a look:
```
float det;
…
if (det*det < 1e-25)
return FALSE;
```
Notice that 1e-25 is *way* smaller than FLT_EPSILON. This
check is fundamentally flawed.
"In practice, what does it break?", the reader might ask.
Well, in this case, the answer is opposite of that: Cogl
inverts matrices that should not be invertible. Let's see
an example: the model-view-projection of a 4K monitor. It
looks like this:
```
| +0,002693 +0,000000 +0,000000 +0,000000 |
| +0,000000 -0,002693 +0,000000 +0,000000 |
| +0,000000 +0,000000 +0,002693 +0,000000 |
| -5,169809 +2,908017 -5,036834 +1,000000 |
```
The determinant of this matrix is -0.000000019530306557.
It evidently is smaller than FLT_EPSILON. In this situation,
Cogl would happily calculate the inverse matrix, whereas
Graphene (correctly) bails out and thinks it's a singular
matrix.
This commit works around that by exploiting the maths around
it. The basis of it is:
inverse(scalar * M) = (1/scalar) * M'
which can be extrapolated to:
inverse(M) = scalar * inverse(scalar * M) = M'
In other words, scaling the to-be-inversed matrix, then
scaling the inverse matrix by the same factor, gives us
the desired inverse. In this commit, the scale is calculated
as 1 / (smallest value in the diagonal).
I'm sorry for everyone that has to read through this :(
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1439
Next commits, and this patchset in general, will make this patchset
obsolete, since it'll only test graphene types against each other.
If at all useful, the Euler test should be moved to graphene.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1439
Use dot products to simplify calculations. Because the 'w' column of
the matrix is always summed, use 1.f in the 'w' component of the point
vector.
Because CoglMatrix is column-major and graphene_matrix_t is row-major,
it is necessary to transpose the matrix before retrieving the rows.
When we switch CoglMatrix to be row-major, this transposition will
go away.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1439
This is pretty similar to the other conversions, except we need to
store the matrix flags before operating on it, and update it using
this old value after. That's because cogl_matrix_init_from_array()
marks the matrix as entirely dirty, and we don't want that.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1439
At this point, we are still only changing CoglMatrix APIs internally, and
it should still produce the same output as before.
To achieve this, using graphens matrix implementation, we need to exploit
some knowledge about conventions used in Cogl and graphene respectively.
In Cogl, transformation matrices are equivalent to those of affine
transformation matrices. The convention used by graphene, however, is to
operate on matrices that are transposed compared to their affine
counterparts.
So for example, let's say we want to multiply the affine matrices A and B,
to get C.
A × B = C
The first step is to convert A and B to graphene matrices. We do this by
importing the floating point array, importing it directly using graphene.
Cogl exports its matrix to a column major floating point array. When we
import this in graphene, being row major, we end up with the same matrix,
only transposed.
Cogl Graphene
A <===> Aᵀ
B <===> Bᵀ
We then multiply these imported matrices in reverse
Bᵀ × Aᵀ
which in turn, due to ABᵀ = BᵀAᵀ, gives us
Bᵀ × Aᵀ = (A × B)ᵀ
Our original goal was to find C, thus we know that
A × B = C
That means we can shuffle things around a bit.
A × B = C
Bᵀ × Aᵀ = (A × B)ᵀ
Bᵀ × Aᵀ = Cᵀ
With the same conversion as done when going from Cogl to graphene, only
the other way around, we still end up effectively transposing the matrix
during the conversion.
Graphene Cogl
Cᵀ <===> C
Thus when converting Cᵀ to Cogl, we in fact end up with C.
(Explanation authored by Jonas Ådahl)
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1439
Graphene provides skewing as part of graphene_matrix_t API, and it'll
be easier for the transition to just expose similar API surfaces.
Move the matrix skew methods to CoglMatrix.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1439
Writing tests' output to a log file makes them difficult to debug when
the test might be running on an autobuilder or CI system where only
stdout/stderr are recorded. This is particularly troublesome if a
failure is only reproducible on a particular autobuilder.
Recent Automake versions have the convention that detailed output from
failing tests is written to stdout/stderr, not just to log files, when
the VERBOSE environment variable is set; borrow that convention as a
trigger for producing detailed test output.
This was originally cogl!14, but applies equally to mutter's fork of cogl.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1273
Signed-off-by: Simon McVittie <smcv@debian.org>
This resolves a couple of FIXMEs. The FIXME comments were right in
stating that not *all* journals needed flushing, only the one we
are trying to put on screen needs flushing.
However we can't eliminate all flushes because the winsys swap calls
that follow go directly into OpenGL which knows nothing about cogl
journalling. So the journal *must* be flushed before the swap, to give
OpenGL the correct state.
P.S. If this turns out to cause any bugs then the next best answer is
to just remove the FIXME comments. Because flushing is still the right
thing to do.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1362
Even when a direct client buffer has a compatible format, stride and
modifier for direct scanout, drmModePageFlip() may still fail sometimes.
From testing, it has been observed that it may seemingly randomly fail
with ENOSPC, where all subsequent attempts later on the same CRTC
failing with EBUSY.
Handle this by falling back to flipping after having composited a full
frame again.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1410
When the CoglRenderer didn't set the DMA buffer constructor vfunc, we
return NULL. What we didn't do was set the error, meaning the caller
would crash if it tried to look up why DMA buffer construction failed.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1430
This will be used when screencasting monitors so that if
there's scanout in place, it'll still be possible to blit
it to a PipeWire-owned framebuffer, and stream it.
Add a new 'blit_to_framebuffer' vfunc to CoglScanout, and
implement it in MetaDrmBufferGbm.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1421
In certain situations it's desirable to keep pipelines around for
the whole lifetime of the session. In order to not leak them and
properly clean them up on shutdown, introduce a new mechanism to
create named pipelines that are bound to their correstponding
context and may be used across file boundries.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1372
In order to support the DRM formats DRM_FORMAT_ABGR16161616F and
friends, as well as the wl_shm formats WL_SHM_FORMAT_ABGR16161616F and
friends, cogl needs to have knowledge about said formats too.
We don't have a software implementation of the half point data types
however, so the pack/unpack methods remain unimplemented. We don't need
them for now, so it's not crucial that we add them.
For the GLES2 driver, currently only two formats are supported, and
since we don't currently have pack/unpack implementations, the other
formats will for now remain unsupported, until we have a half float
implementation.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/804
In the case of indirect rendering like the first frame to use mutter's
background wallpaper:
Texture_A -> FBO_B (Texture_B) -> FBO_C (screen)
we would be trying to render the contents of both FBO_B and FBO_C in
the same flush, before the contents of Texture_A had made it to FBO_B.
So when FBO_C wants to use mipmaps of Texture_B they didn't exist yet
and appeared all black. And the blackness would remain for subsequent
frames as cogl has now decided the mipmaps of FBO_B are no longer
"dirty" and don't need refreshing:
FBO_B (Texture_B) (mipmaps_dirty==FALSE but black) -> FBO_C (screen)
We must flush FBO_B before referencing Texture_B for use in rendering
FBO_C. This only happens when Texture_A changes (e.g. when the user
changes their background wallpaper) so there's no ongoing performance
penalty from this flush.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1347
The native backend had a plain counter, and the X11 backend used the
CoglOnscreen of the screen; change it into a plain counter in
ClutterStageCogl. This also moves the global frame count setting to the
frame info constuctor.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1285
We currently have mutter set a global frame counter on the frame info in
the native backend, but in order to do this from clutter, change the
frame info construction from being implicitly done so when swapping
buffers to having the caller create the frame info and passing that to
the swap buffers call.
While this commit doesn't introduce any other changes than the API, the
intention is later to have the caller be able to pass it's own state
(e.g. the global frame count) along with the frame info.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1285
The property is deprecated and the current implementation simply
redirects it to ClutterActor::background-color, so remove it.
Also update the tests to set the background color directly.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1332
