As it was originally the function to be used before
making it private and providing safer wrappers around it for x11/win32.
Nowadays, it is only used in x11 and only internally in mutter, exposing
a 'safer' variant costs us exposing more of x11 renderer APIs without
much benefits.
With this change, the only internal xlib renderer we need from meta is
set_foreign_display which can't be easily worked around
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3910>
`eglGetProcAddress()` used to not work for core API in EGL versions
below 1.5. The workaround in place in turn can fail - notably for setups
with a local Mesa build in /usr/local.
EGL 1.5 is almost 10 years old and similar workarounds don't seem to be
in place for toolkits we rely on, notably GTK4. Thus remove it.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3655>
meta_render_device_gbm_allocate_dma_buf() function is updated to take a
list of modifiers. If no modifiers are specified, the modifier is
selected by the allocator, and implicit modifiers are used to import the
created DMA-BUF.
Co-authored-by: Jonas Ådahl <jadahl@gmail.com>
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3537>
Group all the three config files from clutter/cogl/meta into one
and also remove unnused configurations and replace duplicated ones
This also fixes Cogl usage of HAS_X11/HAS_XLIB to match the expected
build options
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3368>
These were leftovers from times when GL(ES) 1.x was still supported.
As we require HAVE_COGL_GL and/or HAVE_COGL_GLES2 to be defined, all
cases for checking both are now redundant.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3338>
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>
Returns TRUE if the active renderer backend can allocate DMA buffers.
This is the case hardware accelerated GBM backends, but FALSE for
surfaceless (i.e. no render node) and EGLDevice (legacy NVIDIA paths).
While software based gbm devices can allocate DMA buffers, we don't want
to allocate them for offscreen rendering, as we really only use these
for inter process transfers, and as buffers allocated for scanout
doesn't use the relevant API, making it return FALSE for these solves
that.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1939>
We need to call eglBindAPI() with GLES before we setup the secondary
GPU blit. We've been lucky not really needing this, as it has been
GLES default, which is what the secondary blit uses, in order to not
depend on the default, or if we want to create the secondary blit
objects after initializing cogl, we must make sure to bind the right API
at the right time.
As we need to bind the GLES API when setting up the secondary blit, we
need to make sure that cogl gets the right API bound when that's done,
so Cogl can continue working. For this, add a "bind_api()" method on the
CoglRenderer object, that will know what API is correct to bind.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1828>
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 is a winsys-specific API that allows exporting a DMA buffer fd.
The CoglDmaBufHandle structure allows passing the ownership of the
DMA buffer to whoever is using it, so the winsys doesn't need to
manually track it.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/1086
At this point only the gl driver is at all aware of the difference
between core and compat contexts. COGL_PRIVATE_FEATURE_GL_FIXED is also
now quite misnamed, since we're using the GLSL pipeline even for pre-GL3
contexts. Remove the private feature and handle the few remaining
differences by checking the driver class inside the gl driver.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/973
There are still environment variables for these controls, but having
them in a config file doesn't really make sense for mutter. Even if it
did we probably don't want to be parsing the same file as some
standalone version of cogl.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/902
Threaded swap wait was added for using together with the Nvidia GLX
driver due to the lack of anything equivalent to the INTEL_swap_event
GLX extension. The purpose was to avoid inhibiting the invocation of
idle callbacks when constantly rendering, as the combination of
throttling on swap-interval 1 and glxSwapBuffers() and the frame clock
source having higher priority than the default idle callback sources
meant they would never be invoked.
This was solved in gbz#779039 by introducing a thread that took care of
the vsync waiting, pushing frame completion events to the main thread
meaning the main thread could go idle while waiting to draw the next
frame instead of blocking on glxSwapBuffers().
As of https://gitlab.gnome.org/GNOME/mutter/merge_requests/363, the
main thread will instead use prediction to estimate when the next frame
should be drawn. A side effect of this is that even without
INTEL_swap_event, we would not block as much, or at all, on
glxSwapBuffers(), as at the time it is called, we have likely already
hit the vblank, or will hit it soon.
After having introduced the swap waiting thread, it was observed that
the Nvidia driver used a considerable amount of CPU waiting for the
vblank, effectively wasting CPU time. The need to call glFinish() was
also problematic as it would wait for the frame to finish, before
continuing. Due to this, remove the threaded swap wait, and rely only on
the frame clock not scheduling frames too early.
Fixes: https://bugzilla.gnome.org/show_bug.cgi?id=781835
Related: https://gitlab.gnome.org/GNOME/mutter/issues/700
[jadahl: Rewrote commit message]
https://gitlab.gnome.org/GNOME/mutter/merge_requests/602
This was introduced in:
commit 010d16f647
Author: Robert Bragg <robert@linux.intel.com>
Date: Tue Mar 6 03:21:30 2012 +0000
Adds initial GLES2 integration support
This makes it possible to integrate existing GLES2 code with
applications using Cogl as the rendering api.
That's maybe a reasonable thing for a standalone cogl to want, but our
cogl has only one consumer. So if we want additional rendering out of
our cogl layer, it makes more sense to just add that to cogl rather than
support clutter or mutter or the javascript bindings creating their own
GLES contexts.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/500
