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
The depth buffer is marked as invalid when 1) the framebuffer is just created,
and 2) whenever GL_DEPTH_TEST is enabled on it. This will ensure the
framebuffers attached depth buffer (if any) is properly cleared before it's
actually used, while saving needless clears while depth testing is disabled
(the default).
https://bugzilla.gnome.org/show_bug.cgi?id=782344
Since now we don't set the swap throttled value based
on sync-to-vblank, we can effectively remove it from
Cogl. Throttling swap buffers in Cogl is as much a
historical artifact as sync-to-vblank. Furthermore,
it doesn't make sense to disable it on a compositor,
which is the case with the embedded Cogl.
In addition to that, the winsys vfunc for updating
whenever swap throttling changes could also be removed,
since swap throttling is always enabled now.
Removing it means less code, less branches when running,
and one less config option to deal with.
This also removes the micro-perf test, since it doesn't
make sense for the case where Cogl is embedded into the
compositor.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/191
This commit includes following fixes for a few shell scripts:
1. Follow the best practice of quoting variables everywhere unless they
are used in places where word-splitting and globbing can never happen.
2. Replace `command` with $(command) because the latter is easier to use
and read.
3. Don't use "$@" in places expecting a string because it is an array
of strings instead of a single string.
Bash is not always installed in /bin and we should not hardcode the path
of it in source code which is expected to be built on many operating
systems and distributions.
Since most scripts using #!/bin/bash here doesn't have any bashism,
they can be converted to #!/bin/sh instead of using /usr/bin/env trick.
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.
Meson uses the 'dependencies' field to determine and
parallelize build steps, but that isn't entirely true
with 'link_with'; this might cause a race condition
when generating header files while trying to build
them.
Fix that by only using 'dependencies' instead of 'link_with'.
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.
There are different unit-tests file generated containing lists of tests
the test-runner.sh should run. Running run-tests.sh read the unit-tests
in the current directory, which is inconvenient to do when using meson.
