Or else `glXQueryDrawable` will fail per the `GLX_EXT_buffer_age` spec:
> If querying GLX_BACK_BUFFER_AGE_EXT and <draw> is not bound to
> the calling thread's current context a GLXBadDrawable error is
> generated.
This mistake went unnoticed until `mtk_x11_error_trap_push` was introduced
(55e3b2e519) because for some reason it is incapable of trapping
`glXQueryDrawable`. Prior to that it seems
`cogl_onscreen_glx_get_buffer_age` would trap and so always returned zero.
This means we're reenabling clipped redraws on X11 here for the first
time in a long time.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3007
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3255>
Dropped obsolete Free Software Foundation address pointing
to the FSF website instead as suggested by
https://www.gnu.org/licenses/gpl-howto.html
keeping intact the important part of the historical notice
as requested by the license.
Resolving rpmlint reported issue E: incorrect-fsf-address.
Signed-off-by: Sandro Bonazzola <sbonazzo@redhat.com>
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3155>
In future commits, we will want to create DMA-BUFs with pixel
formats other than COGL_PIXEL_FORMAT_BGRX_8888. In preparation
for that, let's start passing a new pixel format parameter to
this function, and the corresponding winsys vfunc.
All callers of this function pass COGL_PIXEL_FORMAT_BGRX_8888
for now. Next commits will change that.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3175>
So we can properly handle matching DRM and WL_SHM formats in a unified
manner.
Add extensive testing between these and existing pre-multiplied alpha
formats, i.e. all formats we support on Wayland.
Note that unfortunately for some format combinations the value in the
alpha channel is not cleared as expected, likely because of fast-paths
in Cogl. If both source and destination format is opaque, it always
works, however. This thereby includes all cases where they are the same.
Co-Authored-By: Jonas Ådahl <jadahl@gmail.com>
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3065>
On GLES2 reading and writing some Cogl formats is not supported
natively. In those cases we use another format to do the reading and
writing. When the internal format and the temporary format differ in
premultiplication, Cogl tries to adjust for it.
Opaque Cogl formats don't have the premult bit set but our internal
format is a premult format. Cogl tries to adjust for it but completely
misses that the opaque format doesn't have an alpha channel and it
should not do so at all.
So skip the premult adjusting when the Cogl format has no alpha channel.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3065>
As it is the only place where cogl depends directly on cairo minus
the whole cairo_region_t.
The motivation behind the removal of this helper is to reduce the usage
of cairo in libmutter is to potentially completely drop it in
certain places or replace it with pixman.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3079>
glGetIntegerv() with GL_RED_BITS/GL_GREEN_BITS/GL_BLUE_BITS/etc. is not
supported with the GL core context, so there is no point in falling back
to that without supporting COGL_PRIVATE_FEATURE_QUERY_FRAMEBUFFER_BITS,
as this will cause an GL error.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3047>
The function ensure_bits_initialized() in cogl-gl-framebuffer-fbo.c
checks for COGL_PRIVATE_FEATURE_QUERY_FRAMEBUFFER_BITS whereas the same
in cogl-gl-framebuffer-back.c simply checks for the driver being
COGL_DRIVER_GL3.
Change the later to use the COGL_PRIVATE_FEATURE_QUERY_FRAMEBUFFER_BITS
flag as well.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3047>
Cogl's feature COGL_PRIVATE_FEATURE_QUERY_FRAMEBUFFER_BITS is required
to use the GL_FRAMEBUFFER_ATTACHMENT_* queries.
Unfortunately, the test for the availability of the private feature is
actually inverted in ensure_bits_initialized() which causes that whole
portion of code to be ignored, falling back to the glGetIntegerv()
method which isn't supported in core profiles.
As Mesa has recently started to be more strict about these, this causes
the CI tests to fail in mutter.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3047>
Don't try to handle things by threads enabling/disabling the main trace
context on-demand, just have a clear start/stop API. For the D-Bus API,
it becomes more straight forward, and for the persistent variant too, as
it avoids having to pass garbage input when it's known that arguments
will be discarded.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2998>
The only consumer of this type of rect was the scissor clipping,
which was removed by the previous commit.
Remove window rects from CoglClipStack, and all dependent code.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3006>
Both Clutter and Cogl use g_return(_val)_if_fail() to safeguard
introspected API. Release builds were dropping these checks, which could
result in a much more crashy experience, especially when considering
extensions, but also due to bugs in the shell code itself.
This won't affect any major distro, because they all use "plain" builds.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2930>
This is a X request that may result in errors, so it is better
to have covered by an error trap.
It is thus far not, explicitly at least, which means other less
lenient error traps might not like what happens here. Make the
error trap threeway between backend, x11 and cogl happen less
by chance here.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2864>
This will later be emitted when a scanout failed, e.g. by the not-test commit
failing for some reason, or drmModePageFlip() failing even if the
pre-conditions for scanout in the simple KMS backend passed.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2854>
Marking the the depth/stencil as discarded before swapping buffers for
the screen signals the GPU that we don't need to keep them around for
the future.
This helps performance by reducing memory bandwidth usage in some GPUs
which may optimize to not write those buffers back to memory at all
after rendering, when they would just be cleared right after that
anyway.
It is not necessary to mark buffers as discarded after swapping buffers.
This should have no effect according to the spec (since that is going to
be followed by new rendering commands which make the buffer valid again)
and removing that has shown no impact in performance tests.
Signed-off-by: Erico Nunes <nunes.erico@gmail.com>
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2091>
cogl_framebuffer_discard_buffers required that the color buffer is
passed, although users might want to discard e.g. just depth and/or
stencil buffers.
Signed-off-by: Erico Nunes <nunes.erico@gmail.com>
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2091>
When sysprof-4 and libsysprof-capture-4 are installed into different
prefixes, such as with Nix package manager, the D-Bus interfaces
are likely not discoverable from the latter package.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2572>
OpenGL requires more hand holding in the driver regarding what pixel
memory layouts can be written when calling glReadPixels(), compared to
GLES2. Lets move the details of this logic to the corresponding
backends, so in the future, the GLES2 backend can be adapted to handle
more formats, without placing that logic in the generic layer.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2461>
COGL_PIXEL_FORMAT_ABGR_2101010 is defined to mean the 2 A bits are
placed in a 32 bit unsigned integer on the bits with highest
significance, followed by B on the following 10 bits, and so on, until R
on the 10 least significant bits.
UNSIGNED_INT_2_10_10_10_REV_EXT is defined to represent color channels
as
```
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
-------------------------------------------------------------------------------------
| a | b | g | r |
-------------------------------------------------------------------------------------
```
As can be seen, this matches COGL_PIXEL_FORMAT_ABGR_2101010, meaning
that's the format we can directly read and write.
In Cogl, when finding the GL formats, we get the tuple with the GL
format given the format we pass, but we also get returned "required
format" (CoglPixelFormat). This required format represents the format
that is required when reading actual pixels from GLES. In GLES, the
above mentioned format is the only one supported by the
EXT_texture_type_2_10_10_10_REV extension, thus for other types, we need
to do the CPU side conversion ourselves. To achieve this, correctly
return COGL_PIXEL_FORMAT_ABGR_2101010 as the required format.
The internal format should also be GL_RGB10_A2, not GL_RGBA.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2461>
