This macro was introduced so as to be able to be built without GLib.
However, this feature was long ago removed, and in Mutter we depend on
it anyway, so let's get rid of it in favor of more consistency.
This is based on `g_clear_object`, so it will be a bit more consistent
to write (and prevents the headaches from accidentally forgetting a NULL
check).
If texture allocation fails (e.g. on an old GPU with size limit 2048)
then `cogl_texture_new_with_size` was trying to use the same CoglError
twice. The second time was after it had already been freed.
Bug reported and fix provided by Gert van de Kraats.
https://launchpad.net/bugs/1790525
This will allow CoglFramebuffer and its implementations to be exposed
to GJS and other language bindings. This is a necessary part of the
bigger work to make framebuffer management explicit.
CoglOffscreen is effectively a CoglFramebuffer, but it isn't being marked as
such by the GType machinery. This makes it impossible for introspection to
correctly set this class up.
Fix that by adding a COGL_GTYPE_IMPLEMENT_INTERFACE() code into the declaration
of CoglOffscreen. This does not have any functional changes though.
This commit adds meson build support to mutter. It takes a step away
from the three separate code bases with three different autotools setups
into a single meson build system. There are still places that can be
unified better, for example by removing various "config.h" style files
from cogl and clutter, centralizing debug C flags and other configurable
macros, and similar artifacts that are there only because they were once
separate code bases.
There are some differences between the autotools setup and the new
meson. Here are a few:
The meson setup doesn't generate wrapper scripts for various cogl and
clutter test cases. What these tests did was more or less generate a
tiny script that called an executable with a test name as the argument.
To run particular tests, just run the test executable with the name of
the test as the argument.
The meson setup doesn't install test files anymore. The autotools test
suite was designed towards working with installed tests, but it didn't
really still, and now with meson, it doesn't install anything at all,
but instead makes sure that everything runs with the uninstalled input
files, binaries and libraries when running the test suite. Installable
tests may come later.
Tests from cogl, clutter and mutter are run on 'meson test'. In
autotools, only cogl and clutter tests were run on 'make check'.
Install include files in
$prefix/include/mutter-$apiversion/[clutter,cogl,...,meta]/, and
datafiles in /usr/share/mutter-$apiversion/.... We still would conflict
e.g. given that our gettext name is "mutter", and how keybindings are
installed, but it's a step in the right direction.
The docs previously suggested that `cogl_frame_info_get_frame_counter`
returned a timestamp of an unknown clock ID. That's not correct. The
cogl source code shows that it does and must use the same clock as
`cogl_get_clock_time`.
Related to https://gitlab.gnome.org/GNOME/mutter/issues/131
Before we just set it to "none", but this was not enough since various
calls will depend on not just the context being active, but the main
rendering surface.
Fixes https://gitlab.gnome.org/GNOME/mutter/issues/21
By the looks of it, commit 95e9fa10ef was taping over an Intel DRI bug
that would make it return post-swizzling pixel data on glReadPixels().
There's been reports over time of that commit resulting in wrong colors
on other drivers, and lately Mesa >17.3 started showing the same symptoms
on Intel.
But texture swizzling works by changing parameters before fragment shaders
and reading pixels from an already drawn FBO/texture doesn't involve those.
This should thus use pixel_format_to_gl_with_target(), which will result in
correctly requesting the same pixel format than the underlying texture,
while still considering it BGRA for the upper layers in the swizzling case.
https://gitlab.gnome.org/GNOME/mutter/issues/72Closes: #72
We just arbitrarily chose the first EGL config matching the passed
attributes, but we then assumed we always got GBM_FORMAT_XRGB8888. That
was not a correct assumption. Instead, make sure we always pick the
format we expect.
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/2
On drivers that do not support glGetTexImage2D (i.e. on GLES),
cogl_texture_get_data() has a "feature" that allows it to download
texture data by rendering the texture on an intermediate framebuffer
object and then reading back the data from there. However, this
feature requires the user to have previously set an "active"
framebuffer object in the context, which makes this very tricky
because it is not clear to the developer that he needs to do that
in order for some code to work on GLES (of course it works on
desktop GL, so nobody notices...) and additionally the code actually
crashes if an active fbo is not set!
This patch basically removes this feature in order to prevent
the crash and is in line with how this code has evolved in cogl-2.0:
https://git.gnome.org/browse/cogl/commit/?id=6d6a277b8e9a63a8268046e5258877ba94a1da5bhttps://bugzilla.gnome.org/show_bug.cgi?id=789961
When creating a renderer with a custom winsys (which is always how
mutter uses cogl) make it possible to pass a user data with the winsys.
Still unused.
https://bugzilla.gnome.org/show_bug.cgi?id=785381
The GL_BGRA definition is not available for GLES2 contexts, which use
the EXT_texture_format_BGRA8888 instead, causing a build failure when
trying to use it in those contexts.
Fortunately, this hack is only relevant for GL, so let's guard it to
prevent the failure in GLES2, where that extension is used instead.
https://bugzilla.gnome.org/show_bug.cgi?id=786568
Those are cached and reused across runs, which doesn't qualify to mesa
as "static" indeed. Properly marking those as dynamic is more true, and
brings in slight performance benefits just by avoiding the resulting
(and later silenced) mesa warning.
https://bugzilla.gnome.org/show_bug.cgi?id=782344
Fixes cogl_texture_get_data() resorting to the wrong conversions when
extracting the texture data. This notably resulted in RGB/RGBA buffers
copied as-is into BGRA buffers, for instance for the fullscreen animation,
or single-window screenshots of such buffers.
https://bugzilla.gnome.org/show_bug.cgi?id=779234
The ARB_robustness extension defined the following tokens as
returned by GetGraphicsResetStatusARB (see spec at [1]):
GUILTY_CONTEXT_RESET_ARB 0x8253
INNOCENT_CONTEXT_RESET_ARB 0x8254
UNKNOWN_CONTEXT_RESET_ARB 0x8255
These tokens might not be defined in some GL implementations,
such as Mesa 13's implementation of GLES 2.0, so we need to
define them ourselves not to break those builds.
[1] https://www.khronos.org/registry/OpenGL/extensions/ARB/ARB_robustness.txthttps://bugzilla.gnome.org/show_bug.cgi?id=781398
We already do have a texture with an internal format in these paths,
so we should check the required format according to it.
This fixes CoglAtlasTexture (and CoglPangoRenderer indirectly), as
it forces a RGBA format on its texture, but pixel_format_to_gl()
anyway assumed swizzling is performed on the texture, while it is
not the case.
https://bugzilla.gnome.org/show_bug.cgi?id=779234
This is used by the GL driver in order to determine whether swizzling
actually applies given the bitmap and target texture internal format.
If both agree that they store BGRA, then swizzling may apply.
https://bugzilla.gnome.org/show_bug.cgi?id=779234
If the GL implementation/hw supports the GL_*_texture_swizzle extension,
pretend that BGRA textures shall contain RGBA data, and let the flipping
happen when the texture will be used in the rendering pipeline.
This avoids rather expensive format conversions when forcing BGRA buffers
into RGBA textures, which happens rather often with WL_SHM_FORMAT_ARGB8888
buffers (like gtk+ uses) in little-endian machines.
In intel/mesa/wayland, the performance improvement is rather noticeable,
CPU% as seen by top decreases from 45-50% to 25-30% when running
gtk+/tests/scrolling-performance with a cairo renderer.
https://bugzilla.gnome.org/show_bug.cgi?id=779234
Because the threaded-swap-wait functionality requires XInitThreads(),
and because it isn't clear that it is a win for all applications,
add a API function to conditionally enable it.
Fix the cogl-crate example not to just have a hard-coded dependency
on libX11.
https://bugzilla.gnome.org/show_bug.cgi?id=779039
It's a good guess that the buffer swap will occur at the next vblank,
so use glXWaitVideoSync in a separate thread to deliver a sync event
rather than just letting the client block when frame drawing, which
can signficantly change app logic as compared to the INTEL_swap_event
case.
https://bugzilla.gnome.org/show_bug.cgi?id=779039
When we don't have GLX_OML_sync_control, we still can set the
frame presentation time, but we always use the system monotonic time,
so return that from get_clock_time().
https://bugzilla.gnome.org/show_bug.cgi?id=779039
As previously commented in the code, SGI_video_sync is per-display, rather
than per-renderer. The is_direct flag for the renderer was tested before
it was initialized (per-display) and that resulted in SGI_video_sync
never being used.
https://bugzilla.gnome.org/show_bug.cgi?id=779039
In order to minimize the amount of breakage, while at the same time
making it easier to make backward incompatible changes needed to
continue turning libmutter into a capable Wayland compositor, make the
libmutter and friends (libmutter-clutter, libmutter-cogl*) parallel
installable by adding a version number to the name. This changes
various filenames, for example what previously was libmutter.so is now
libmutter-0.so (assuming the version for now is 0), and
libmutter-clutter-1.0.so is now libmutter-clutter-0.so. The pkg-config
filenames and GObject introspection has been renamed to reflect this as
well.
This enables a downstream compositor rely on a specific version of the
libmutter API, while gracefully handling API/ABI changes by having to
update to the new version at their own pace.
https://bugzilla.gnome.org/show_bug.cgi?id=777317
Different libEGL will do different things for eglGetDisplay since it has
to guess what kind of display it's been handed. Better to just use the
API that makes it explicit.
Signed-off-by: Adam Jackson <ajax@redhat.com>
https://bugzilla.gnome.org/show_bug.cgi?id=772422
We need a GLES2 extension macro in cogl-texture-2d-gl.c, but we can't
include GLES2/gl2ext.h because it will conflict with things in
GL/glext.h. We can't rely on cogl including anything for us since it'd
only include GLES2/gl2ext.h if OpenGL support was explicitly disabled.
https://bugzilla.gnome.org/show_bug.cgi?id=774891
EGLDevice requires a define from GLES2, even when GL is used instead.
As type definitions may conflict between the two, we shouldn't include
both at the same time. Instead, provide the missing define explicitly
when not using GLES2.
https://bugzilla.gnome.org/show_bug.cgi?id=774891
Add API to enable the caller to have a custom method for allocating an
external texture. This will enable the possibility for mutter to
generate a texture from for example an EGLStream without having to add
support for that in Cogl.
https://bugzilla.gnome.org/show_bug.cgi?id=773629
Don't rely on the Cogl layer having Wayland specific paths by
determining the buffer type and creating the EGLImage ourself, while
using the newly exposed CoglTexture from EGLImage API. This changes the
API used by MetaWaylandSurface to make the MetaWaylandBuffer API be
aware when the buffer is being attached. For SHM and EGL buffers, only
the first time it is attached will result in a new texture being
allocated, but later for EGLStream's, more logic on every attach is
needed.
https://bugzilla.gnome.org/show_bug.cgi?id=773629
The WL_bind_wayland_display spec says that EGL images should be created
using EGL_WAYLAND_BUFFER_WL as the target and a NULL context. Mesa
seems to be lenient and accept any context, however some other stacks
aren't so forgiving and fail if anything apart from EGL_NO_CONTEXT is
used.
Signed-off-by: Sjoerd Simons <sjoerd.simons@collabora.co.uk>
https://bugzilla.gnome.org/show_bug.cgi?id=769731
Mutter (and libmutter users) are the only users of this version of
cogl, and will more or less only use the cogl-1.0, cogl-2.0 and cogl
experimental API variants, and having the possibility of having
different API versions of the same API depending on what file includes
it is error prone and confusing. Lets just remove the possibility of
having different versions of the same API.
https://bugzilla.gnome.org/show_bug.cgi?id=768977
We bypass our build configuration to fetch API from a version which
isn't the one we actually use. Stop bypassing and just admit that the
1.0 API is still there, but still deprecated.
https://bugzilla.gnome.org/show_bug.cgi?id=768977
CoglFrameInfo is a frame info container associated with a single
onscreen framebuffer. The clutter stage will eventually support drawing
a stage frame with multiple onscreen framebuffers, thus needs its own
frame info container.
This patch introduces a new stage signal 'presented' and a accompaning
ClutterFrameInfo and adapts the stage windows and past onscreen frame
callbacks users to use the signal and new info container.
https://bugzilla.gnome.org/show_bug.cgi?id=768976
Move the KMS interaction from cogl into mutter, where most of the other
KMS interaction already takes place. This also removes dead code which
were only excercised when non-mutter callers used the cogl KMS backend.
The cogl KMS API was updated to pass via MetaRendererNative instead of
via the different cogl objects.
https://bugzilla.gnome.org/show_bug.cgi?id=768976
In cogl use cogl-config.h and in clutter use clutter-build-config.h. We
can't use clutter-config.h in clutter because its already used and
installed.
https://bugzilla.gnome.org/show_bug.cgi?id=768976
If you include a file that might define __INSIDE_COGL_H__, don't
undefine it if it wasn't defined in that file. This makes it possible
to include for example cogl-gles2.h from some other file which defines
__INSIDE_COGL_H__.
https://bugzilla.gnome.org/show_bug.cgi?id=768976
When using a context with robustness, glGetError() may return
GL_CONTEXT_LOST at any time and this error doesn't get cleared until
the application calls glGetGraphicsResetStatus() . This means that our
error checking can't call glGetError() in a loop without checking for
that return value and returning in that case.
https://bugzilla.gnome.org/show_bug.cgi?id=739178
