The function create_texture() in test-wrap-modes.c takes a
TestUtilsTextureFlags. However a CoglTextureFlags is passed instead
in two calls. As the enums are identical this patch changes it to
use the TestUtils type.
The enum definitions:
typedef enum
{
COGL_TEXTURE_NONE = 0,
COGL_TEXTURE_NO_AUTO_MIPMAP = 1 << 0,
COGL_TEXTURE_NO_SLICING = 1 << 1,
COGL_TEXTURE_NO_ATLAS = 1 << 2
} CoglTextureFlags;
typedef enum
{
TEST_UTILS_TEXTURE_NONE = 0,
TEST_UTILS_TEXTURE_NO_AUTO_MIPMAP = 1 << 0,
TEST_UTILS_TEXTURE_NO_SLICING = 1 << 1,
TEST_UTILS_TEXTURE_NO_ATLAS = 1 << 2
} TestUtilsTextureFlags;
https://gitlab.gnome.org/GNOME/mutter/merge_requests/938
In _cogl_offscreen_gl_allocate we only want to perform certain actions if
COGL_OFFSCREEN_DISABLE_DEPTH_AND_STENCIL is not set in create_flags.
We perfrom this check with:
if (!offscreen->create_flags & COGL_OFFSCREEN_DISABLE_DEPTH_AND_STENCIL)
which is not correct as we negate the create_flags before the bitwise &.
It happens to work as intended though, as CoglOffscreenFlags only has one
element, and that element has the value 1. If the flag is not set then the
nagation of create_flags is true and the bitwise and with the element value
is true as well.
If any flag is set then the negation will give 0 and the bitwise & will be
false.
So while it works correctly it is fragile as either additional flags or a
change in the enum element value will break this check. This patch makes
things a bit more safe by adding parentheses to let the bitwise & happen
before the negation.
Definition of the enum:
typedef enum
{
COGL_OFFSCREEN_DISABLE_DEPTH_AND_STENCIL = 1
} CoglOffscreenFlags;
https://gitlab.gnome.org/GNOME/mutter/merge_requests/938
cogl_pipeline_get_front_face_winding() is supposed to return a CoglWinding. It
takes a CoglPipeline as argument and does the following input validation:
g_return_val_if_fail (cogl_is_pipeline (pipeline),
COGL_PIPELINE_CULL_FACE_MODE_NONE);
The returned COGL_PIPELINE_CULL_FACE_MODE_NONE is not a winding.
The function was added with this check 8 years ago in
5369b3c601
I do not see any of the two options in the CoglWinding as particularly good
choice for a return value on bad input, but let's go with
COGL_WINDING_CLOCKWISE as that is equivalent with the behavior for all
these years.
Definitions of the two enums:
typedef enum
{
COGL_WINDING_CLOCKWISE,
COGL_WINDING_COUNTER_CLOCKWISE
} CoglWinding;
typedef enum
{
COGL_PIPELINE_CULL_FACE_MODE_NONE,
COGL_PIPELINE_CULL_FACE_MODE_FRONT,
COGL_PIPELINE_CULL_FACE_MODE_BACK,
COGL_PIPELINE_CULL_FACE_MODE_BOTH
} CoglPipelineCullFaceMode;
https://gitlab.gnome.org/GNOME/mutter/merge_requests/934
As noted in <cogl-texture-2d-gl.h> (now also removed), this is for
allowing external GL callers to promote one of their textures to a
CoglTexture. We aren't doing that and don't want to start.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/883
Unknown since when, we started deferring the eglMakeCurrent for the
current framebuffer till we started painting on it, which means we
are preparing for rendering a view without guarantees that the
framebuffer we will paint to is the current drawing surface for the
EGL context.
A fairly common case where that assumption will break is multimonitor
set ups, in this case we will be preparing to paint to a view while
the current draw surface is that of the previously rendered view's.
Mesa will in this case return EGL_BAD_SURFACE when querying the buffer
age, since the surface is not yet the current draw surface. This
makes us give up on buffer age checks, and paint the whole view. Since
the problem repeats when painting the next view, we are effectively
doing full-screen redraws on all monitors.
Since cogl usually works implicitly, and querying the buffer age is
meaningless if you're not meant to paint on a surface, make the surface
the current draw surface implicitly before querying the buffer age.
This brings us glorious partial invalidations back when several views
had to be repainted.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/906
In order to avoid log spamming, just warn once it starts to happen, not
on every frame for every onscreen. Just knowing that this is happening
is a hint that something's going wrong.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/906
Say you're using intel gen3, you poor soul. Your big-GL maxes out at 1.5
unless you use dirty tricks, but you do have GLES2. We try to fall back
to GLES in this case, but we only ever say eglBindAPI(EGL_OPENGL_API).
So when we go to do CreateContext, even though we think we've requested
GLES 2.0, the driver will compare that "2.0" against the maximum big-GL
version, and things will fail.
Fix this by binding EGL_OPENGL_ES_API before trying a GLES context.
https://gitlab.gnome.org/GNOME/mutter/issues/635
In find_onscreen_for_xid() we want to loop over the framebuffers
and skip any that is not onscreen.
The code today does this by negating the framebuffer type variable
and skipping if that equals COGL_FRAMEBUFFER_TYPE_ONSCREEN. This
actually works as the enum used will function as a boolean:
typedef enum _CoglFramebufferType {
COGL_FRAMEBUFFER_TYPE_ONSCREEN,
COGL_FRAMEBUFFER_TYPE_OFFSCREEN
} CoglFramebufferType;
But it is a bit weird logic and fragile if more types are added.
(not that I can think of any different type...)
To simplify this, and to silence a warning in clang this patch just
changes it to a != test.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/905
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
This is a _little_ strange, as we still fill in the vtable slot for
glRenderbufferStorageMultisampleIMG, and can in principle still call it.
But that feature was weird to begin with as we were only checking for
that function in big-GL contexts despite that its extension is for GLES.
I'll leave cleaning that up to a future pass.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/866
This was only promoted to core in 3.0, but Mesa's supported it
unconditionally since around 7.0 even in 2.1 contexts, so this is not a
particularly onerous requirement.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/866
Midscene tracking was used at a time that some Cogl users
could call random OpenGL API without going through Cogl.
That is not allowed anymore, and certainly not done by
Mutter and GNOME Shell.
Remove midscene tracking from CoglFramebuffer.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/402
CoglJournal tracks a few OpenGL states so that they can
be batch-applied if necessary. It also has a nice property
of allowing purely CPU-based glReadPixels() when the scene
is composed of simple rectangles.
However, the current journal implementation leaves various
other GL states out, such as dithering and the viewport.
In Clutter, that causes the journal to be flushed when
picking, touching the GPU when we didn't really need to.
Track the viewport of the framebuffer in the journal so that
we can avoid flushing the journal so often.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/402
CoglFramebuffer checks the passed buffer bits in order to
detect when the fast path (that uses the journal) should
be used.
However, it also modifies one of the buffer bits that is
checked for the fast path, meaning we never actually hit
the fast path on cogl_framebuffer_cleaf4f().
Check the depth and color buffer bits before modifying them.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/402
This is an extremely straightforward and minimalistic port of
CoglVector APIs to the corresponding Graphene APIs.
Make ClutterPlane use graphene_vec3_t internally too, for the
simplest purpose of keeping the patch focused.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/458
As the first step into removing Cogl types that are covered by
Graphene, remove CoglEuler and replace it by graphene_euler_t.
This is a mostly straightforward replacement, except that the
naming conventions changed a bit. Cogl uses "heading" for the
Y axis, "pitch" for the X axis, and "roll" for the Z axis, and
graphene uses the axis themselves. That means the 1st and 2nd
arguments need to be swapped.
Also adapt the matrix stack to store a graphene_euler_t in the
rotation node -- that simplifies the code a bit as well.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/458
Graphene is a small library with data types and APIs
specially crafted to computer graphics. It contains
performant implementations of matrices, vectors, points
and rotation tools. It is performance because, among
other reasons, it uses vectorized processor commands
to compute various operations.
Add Graphene dependency to Mutter.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/458
Fog is explicitly deprecated in favour of CoglSnippet API,
and in nowhere we are using this deprecated feature, which
means we can simply drop it without any sort of replacement.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/458
As we will start adding support for more pixel formats, we will need to
define a notion of planes. This commit doesn't make any functional
change, but starts adding the idea of pixel formats and how they (at
this point only theoretically) can have multple planes.
Since a lot of code in Mutter assumes we only get to deal with single
plane pixel formats, this commit also adds assertions and if-checks to
make sure we don't accidentally try something that doesn't make sense.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/858
This is for all intents and purposes the same as
`cogl_object_ref/unref`, but still refers to handles rather than
objects (while we're trying to get rid of the former) so it's a bit of
unnecessary redundant API.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/451
It wasn't necessary (see other instances of -DG_LOG_DOMAIN) and somewhere
along the line it was getting turned into forward slashes becoming a syntax
error:
```
/usr/include/glib-2.0/gobject/gobject.h:767: syntax error, unexpected '/' in
...
g_assertion_message (/"CoglPango/",
```
https://gitlab.gnome.org/GNOME/mutter/merge_requests/841
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
The function will be used in copying from a primary GPU framebuffer to a
secondary GPU framebuffer using the primary GPU specifically when the
secondary GPU is not render-capable.
To allow falling back in case glBlitFramebuffer cannot be used, add boolean
return value, and GError argument for debugging purposes.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/615
Depends on "cogl: Replace ANGLE with GLES3 and NV framebuffer_blit"
Allow blitting between onscreen and offscreen framebuffers by doing the y-flip
as necessary. This was not possible with ANGLE, but now with ANGLE gone,
glBlitFramebuffer supports flipping the copied image.
This will be useful in follow-up work to copy from onscreen primary GPU
framebuffer to an offscreen secondary GPU framebuffer.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/615
Depends on: "cogl: Replace ANGLE with GLES3 and NV framebuffer_blit"
As a possible ANGLE implementation is not longer limiting the pixel format
matching, lift the requirement of having the same pixel format.
We still cannot do a premult <-> non-premult conversion during a blit, so guard
against that.
This will be useful in follow-up work to copy from onscreen primary GPU
framebuffer to an offscreen secondary GPU framebuffer if the formats do not
match exactly.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/615
ANGLE extensions are only provided by Google's Almost Native Graphics Layer
Engine (ANGLE) implementation. Therefore they do not seem too useful for
Mutter.
The reason to drop GL_ANGLE_framebuffer_blit support is that it has more
limitations compared to the glBlitFramebuffer in GL_EXT_framebuffer_blit,
GL_NV_framebuffer_bit, OpenGL 3.0 and OpenGL ES 3.0. Most importantly, the
ANGLE version cannot flip the image while copying, which limits
_cogl_blit_framebuffer to only off-screen <-> off-screen copies. Follow-up work
will need off-screen <-> on-screen copies.
Instead of adding yet more capability flags to Cogl, dropping ANGLE support
seems appropriate.
The NV extension is added to the list of glBlitFramebuffer providers because it
provides the same support as ANGLE and more.
Likewise OpenGL ES 3.0 is added to the list of glBlitFramebuffer providers
because e.g. Mesa GLES implementation usually provides it and that makes it
widely available, again surpassing the ANGLE supported features.
Follow-up patches will lift some of the Cogl assumptions of what
glBlitFramebuffer cannot do.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/615
Public functions in C should be declared before they are defined, and
often compilers warn you if you haven't:
```
../cogl/cogl/cogl-trace.c:237:1: warning: no previous prototype for
‘cogl_set_tracing_enabled_on_thread_with_fd’ [-Wmissing-prototypes]
cogl_set_tracing_enabled_on_thread_with_fd (void *data,
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../cogl/cogl/cogl-trace.c:245:1: warning: no previous prototype for
‘cogl_set_tracing_enabled_on_thread’ [-Wmissing-prototypes]
cogl_set_tracing_enabled_on_thread (void *data,
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../cogl/cogl/cogl-trace.c:253:1: warning: no previous prototype for
‘cogl_set_tracing_disabled_on_thread’ [-Wmissing-prototypes]
cogl_set_tracing_disabled_on_thread (void *data)
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
```
In this case the function declarations were not included because
`HAVE_TRACING` isn't defined. But we should still include `cogl-trace.h`
because it handles the case of `HAVE_TRACING` not being defined and
correctly still declares the functions defined in `cogl-trace.c`.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/650
`cogl_util_memmem` was used as a wrapper in case `memmem` wasn't
defined, but since commit 46942c24 these are required. In case of
`memmem`, we didn't explicitly require this in the meson build files, so
add that as well.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/629
These are implemented in the Meta namespace these days, where we have
better abstractions for wayland-related types. They also weren't used
anymore, since we removed the unused ClutterWaylandSurface type in the
previous commit.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/624
The idea here is to be able to visualize and immediately
understand what is happening. Something like:
```
[ view1 ] [ view2 ]
[---- Layout ---][------ Paint ------][ Pick ]
[================== Update =====================]
```
But with colors. A few of the previous profiling data
sections were removed, since they didn't really add to
reading the graph.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/197
Add the ability to add tracing instrumentation to the code. When
enabled, trace entries will generate a file with timing information
that will be processable by sysprof for generating visualization of
traces over time.
While enabled by default at compile time, it is possible to disable the
expansion of the macros completely by passing --disable-tracing to
./configure.
Tracing is so far only actually done if actually enabled on explicitly
specified threads.
This will be used by Mutter passing the write end of a pipe, where the
read end is sent to Sysprof itself via the D-Bus method 'Capture()'.
By passing that, we have to detect EPIPE that is sent when Sysprof stops
recording. Fortunately, we already ignore the signal at meta_init(), so
no need to add a custom signal handler.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/197
Add debug flags based on meson's `debug` option instead of `buildtype`.
This allows custom build configurations to behave like a debug or release build.
Add `-fno-omit-frame-pointer` to Mutter/Cogl. Not to Clutter though, as that would
require more changes to how Clutter's gir is created
Remove `-DG_DISABLE_CAST_CHECKS` from Clutter in debug builds
Add `-DG_DISABLE_CHECKS`, `-DG_DISABLE_ASSERT` and `-DG_DISABLE_CAST_CHECKS` to all
non-debug builds but `plain`, which explicitly should not have any compile flags
Use `cc.get_supported_arguments`, so it becomes more obvious to the user which flags
are set during compilation
https://gitlab.gnome.org/GNOME/mutter/merge_requests/497
When free'ing a pipeline we destroy the BigState first and then the fragment and
vertex snippets lists using the big state pointer which is now invalid.
This causes a crash when G_SLICE=always-malloc is set and using MALLOC_CHECK_.
So, invert the operations by free'ing the snippet lists first, and the big state
afterwards.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/581
XLib renderer saves its data as the object cogl user data, however this data
is free'd as part of the object destruction that happens before free'ing the
renderer in _cogl_renderer_free(), from where we're calling the renderer
disconnect vfunc.
Thus in _cogl_xlib_renderer_disconnect() we happen to get an invalid pointer to
CoglXlibRenderer and we try access to it in order to close the X11 display.
This causes all the cogl tests to crash when G_SLICE=always-malloc is set and
when using MALLOC_CHECK_.
Fix this using the renderer winsys custom data instead of using cogl object data
for storing the CoglXlibRenderer, and handling the destruction of it manually.
As bonus this also makes access to the renderer data faster.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/581
By providing an (internal) table to map `CoglPixelFormat`s to their
respective properties we will be able to get rid of the unusual enum
values in the future. This is something we will need once we want to
have support for more pixel formats (such as YUV-based formats).
As an extra feature, we provide a `to_string()` method, which is quite
useful for debugging purposes (rather than deciphering enum values).
https://gitlab.gnome.org/GNOME/mutter/merge_requests/524
We're going to add some features and extra code to CoglPixelFormat, so
it's much nicer to have it in once place. Notice also that it doesn't
make sense that e.g. `_cogl_pixel_format_get_bytes_per_pixel()` were in
a private header, since they were being exported anyway.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/524
GList's used in legacy code were free'd using a g_slist_foreach + g_slist_free,
while we can just use g_slist_free_full as per GLib 2.28.
So replace code where we were using this legacy codepath.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/576
GList's used in legacy code were free'd using a g_list_foreach + g_list_free,
while we can just use g_list_free_full as per GLib 2.28.
So replace code where we were using this legacy codepath.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/576
Cogl unit tests are just functions inside normal code files that needs to be
dload'ed by the test binary.
So in case unit-tests are enabled, we need to export those symbols.
Since map file can't be overridden, use a configure_file to generate the map
file when tests are enabled, in order to export the needed symbols.
Then goes through the source files to look unit tests checking for their macro
definition and load them with the runner script.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/442
Use find-conform-unit-tests.sh to create a meson list of tests to run.
This allows to run each test as single test with meson and to remove the timeout
for all the tests.
Instead of changing 'run-tests.sh' to take test-names as arguments we can just
generate simple dummy test-files for each test, without having to change the
tooling.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/442
We already effectively require GLSL, because there's no fixed-function
backend anymore. OpenGL 2.0 drivers don't really exist in the wild, so
just go ahead and require 2.1 or better. 2.1 implies GLSL 1.20 or
better, so simplify that as well.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/489
This is effectively a revert of:
commit 6cfc93f26f
Author: Robert Bragg <robert@linux.intel.com>
Date: Tue Oct 2 11:44:00 2012 +0100
clip-stack: workaround intel gen6 viewport clip bug
It's been over six years, if this bug is still present we should just
fix Mesa already.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/481
If a second `set_{sync,complete}_pending` was queued before the idle
handler had flushed the first then one of them would be forgotten.
It would stay queued forever and never emitted as a notification.
This could happen repeatedly causing a slow leak. But worse still,
`clutter-stage-cogl` would then have `pending_swaps` permanently stuck
above zero preventing the presentation timing logic from being used.
The problem is that a boolean can only count to one, but in some cases
(triple buffering, whether intentional or accidental #334) we need it to
count to two. So just change booleans to integers and count properly.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/216
Meson 0.50.0 made passing an absolute path to install_headers()'
subdir keyword a fatal error. This means we have to track both
relative (to includedir) paths for header subdirs and absolute
paths for generated headers now :-(
https://gitlab.gnome.org/GNOME/mutter/merge_requests/492
As it was originally reported on
https://bugzilla.gnome.org/show_bug.cgi?id=779234#c0, the hottest path was
convert_ubyte() in mesa. Reverting this shows no trace of those hot paths,
nor any higher than usual CPU activity.
As the improvements at the time were real, I can only conclude that pixel
conversion was happening somewhere further the pipeline, and swizzling just
helped indirectly. That got eventually fixed, so swizzling just stayed to
cause grief. And lots it caused.
Time to bin this, it seems.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/486
This basically reverts commit 54735dec, which tried to avoid the
GLib-defined types in favor the standard C ones. One exception to this
is the bool type, for which the commit introduces a new type CoglBool.
Let's just get rid of this type in favor of having consistency with the
GLib types. Note by the way that neither CoglBool nor gboolean (which
has a size of `int`) are completely compatible with bool (size `char`).
https://gitlab.gnome.org/GNOME/mutter/merge_requests/321
Until meson 0.50, setting the install parameter in 'configure_file' is ignored
if 'install_dir' is set. Then until mutter doesn't depend on such meson version
cogl_installed_tests_libexecdir should be empty unless have_installed_tests is
false, or this file will be installed anyway.
See https://github.com/mesonbuild/meson/issues/4160
Commit 25f416c13d added additional compilation warnings, including
-Werror=return-type. There are several places where this results
in build failures if `g_assert_not_reached()` is disabled at compile
time and the compiler misses a return value.
https://gitlab.gnome.org/GNOME/mutter/issues/447
pkg-config files for mutter are generated using *_pkg_deps as requires, but
programs linked with libmutter doesn't need most of these private dependencies
which are only needed for building and linking mutter and its subprojects.
So list packages needed only by mutter itself inside *_pkg_private_deps and
don't expose such packages to pkg-config, but only use them at build time.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/3955
Soname of the libraries should be the major version number, while the version
triplet is currently used:
objdump -p libmutter-4.so.0.0.0 | grep SONAME
SONAME libmutter-4.so.0.0.0
While is expected to be only libmutter-4.so.0
Fix all shared libraries by setting valid version and soversion.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/3955
Map files were using wrong syntax (missing final `;` or invalid chars).
Also, the map files were only monitored for rebuilding, but not really used by
ld, so pass the ldflags with version-script so that private symbols are really
hidden.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/395
In plenty of places a non-static function was defined but didn't have
the corresponding declaration. Fix this by adding them, or alternatively
making them static.
cogl-path uses types from glu.h, but to avoid a build dependency on glu,
it kept a minified copy of glu.h in tree. Drop this file and just use
the actual glu.h. To avoid linking to libGLU.so, just use the
includepath, instead of actually adding glu as a real dependency.
This means we can remove an includepath meant to make it possible to
include <GL/glu.h>.
gluTessCallback() expects an equivalent to a GFunc, but we pass
functions with arguments without casting. To get rid of warnings, cast
the callback function pointer to the expected type.
I saw Meson fade from the sky
On the wind I heard a sigh
As snowflakes cover fallen Makefiles
I will say this last goodbye
Meson is now coming
So ends Autotools days
Future is now coming
And we must away
Over Python and without Bashisms
Through lands where never Meson touched
By silver streams that run down to the Sea
Under parsers, beneath old legacy
Over snow one winter’s morn
I turned at last to paths that lead home
And though where the road then takes me
I cannot tell
We came all this way
But now comes the day
To bid you farewell
Many places I have been
Many sorrows I have seen
But I don’t regret
Nor will I forget
All Makefiles that took that road with me
I bid you all a very fond farewell.
If a library is provided in the positional arguments, then meson
defaults to installing the .pc file in a 'pkgconfig' subdirectory
in the library's install location. We want the files in the regular
$libdir/pkgconfig rather than $libdir/mutter-$api/pkgconfig, so
specify the location explicitly in the parameters.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/382
Dependencies are added automatically, and we no longer get warnings
like:
clutter/clutter/meson.build:628: DEPRECATION: Library mutter-clutter-4
was passed to the "libraries" keyword argument of a previous call to
generate() method instead of first positional argument. Adding
mutter-clutter-4 to "Requires" field, but this is a deprecated behaviour
that will change in a future version of Meson. Please report the issue
if this warning cannot be avoided in your case.
While for normal textures, GL_TEXTURE_2D should be used, when it's an external
texture, binding it using GL_TEXTURE_2D results in an error.
Reading the specification for GL_TEXTURE_EXTERNAL_OES it is unclear whether
getting pixel data from a texture is possible, and tests show it doesn't result
in any data, but in case it would eventually start working, at least bind the
correct target for now.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/362
Don't just set the internal format to the dummy format "any", as that causes
code intended to be unreachable code to be reached. It's not possible to
actually know the internal format of an external texture, however, so it might
not actually correspond to the real format.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/362
This makes the build less verbose, as all .gir generation except for
clutters didn't pass --quiet to g-ir-scanner, making it output long
linking commands. Do this by adding a common introspection_args
variable.
While at it, put -U_GNU_SOURCE in there too, as it was always passed
everywhere as without it the scanner would log warnings.
This is the last remaining feature necessary to achieve
parity with the Autotools build.
A few changes were made to the install locations of the
tests, in order to better acomodate them in Meson:
* Tests are now installed under a versioned folder (e.g.
/usr/share/installed-tests/mutter-4)
* The mutter-cogl.test file is now generated from an .in
file, instead of a series of $(echo)s from within Makefile.
Notice that those tests need very controlled environments
to run correctly. Mutter installed tests, for example, will
failed when running under a regular session due to D-Bus
failing to acquire the ScreenCast and/or RemoteScreen names.
When running installed tests, the working directory for Cogl
tests is /usr/libexec/installed-tests/mutter-cogl-4/conform,
which isn't writable by normal users.
To avoid the adding stray hidden files to the current directory,
adapt the runner script to fallback to $(mktemp) - which is
available on all platform we care about - and avoid adding
hidden files everywhere.
Presumably glReadPixels itself can be more performant with pixel format
conversions than doing a fix-up conversion on the CPU afterwards. Hence,
pick required_format based on the destination rather than the source, so
that it has a better chance to avoid the fix-up conversion.
With CoglOnscreen objects, CoglFramebuffer::internal_format (the source
format) is also wrong. It is left to a default value and never set to
reflect the reality. In other words, read-pixels had an arbitrary
intermediate pixel format that was used in glReadPixels and then fix-up
conversion made it work for the destination.
The render buffers (GBM surface) are allocated as DRM_FORMAT_XRGB8888.
If the destination buffer is allocated as the same format, the Cogl
read-pixels first converts with glReadPixels XRGB -> ABGR because of the
above default format, and then the fix-up conversion does ABGR -> XRGB.
This case was observed with DisplayLink outputs, where the native
renderer must use the CPU copy path to fill the "secondary GPU"
framebuffers.
This patch stops using internal_format and uses the desired destination
format instead.
_cogl_framebuffer_gl_read_pixels_into_bitmap() will still use
internal_format to determine alpha premultiplication state and multiply
or un-multiply as needed. Luckily all the formats involved in the
DisplayLink use case are always _PRE and so is the default
internal_format too, so things work in practise.
Furthermore, the GL texture_swizzle extension can never apply to
glReadPixels. Not even with FBOs, as found in this discussion:
https://gitlab.gnome.org/GNOME/mutter/issues/72
Therefore the target_format argument is hardcoded to something that can
never match anything, which will prevent the swizzle from being assumed.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/313
This function gets hit even today on relatively modern Intel systems (I
have a Haswell Desktop with Mesa 18.2.4) if the pixel format is right.
Presumably it makes things slower for no longer a reason.
According to cb146dc515, this
functionality was refactored into a workaround path in 2012. The commit
message mentions the problem existing before Mesa 8.0.2. The number
refers to https://bugs.freedesktop.org/show_bug.cgi?id=46631 .
The use case where I hit this is when improving support for DisplayLink
video outputs. These are used through a "secondary GPU", and since
DisplayLink does not have a GPU, Mutter uses the CPU copy path with Cogl
read-pixels[1]. If the DisplayLink framebuffer was allocated as
DRM_FORMAT_XRGB8888 (the only format it currently handles correctly),
mesa_46631_slow_read_pixels_workaround would get hit. The render buffer is
the same format as the framebuffer, yet doing the copy XRGB -> XRGB ends
up being slower than XRGB -> XBGR which makes no sense.
This patch is not sufficient to fix the XRGB -> XRGB copy performance,
but it is required.
This patch reverts CoglGpuInfoDriverBug into what it was before
cb146dc515.
[1] This is not actually true until
https://gitlab.gnome.org/GNOME/mutter/merge_requests/278 is
merged.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/313
