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
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.
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
commit 188752158 changed cogl to stop needlessly creating its own
monitor output configuration when mutter would just soon overwrite
it anyway.
Unfortunately, that commit is causing a crash in some cases because
cogl will now create and later draw to a 0x0 egl surface until mutter
sets the monitor layout.
This commit changes cogl to avoid creating and using a surface, before
it knows how big of a surface to create.
https://bugzilla.gnome.org/show_bug.cgi?id=758073
If we get EACCES from drmPageFlip we're not going to get
a flip event and shouldn't wait for one.
This commit changes the EACCES path to silently ignore the
failed flip request and just clean up the fb.
https://bugzilla.gnome.org/show_bug.cgi?id=756926
ES3 provides glMapBufferRange as core, with the added bonus that it also
supports read mappings. Use this where possible.
Signed-off-by: Daniel Stone <daniels@collabora.com>
https://bugzilla.gnome.org/show_bug.cgi?id=728355
GLES2 does not support passing READ to glMapBuffer; attempting to call
cogl_buffer_map for read on ES2 will bring it down with an assert. Make
sure COGL_DEBUG=journal doesn't do this when it's not possible.
Signed-off-by: Daniel Stone <daniels@collabora.com>
https://bugzilla.gnome.org/show_bug.cgi?id=728355
On Wayland deinit() of an onscreen buffer is going to destroy the
associated native window of an EGLSurface. So we should destroy the
EGLSurface as well otherwise we might end up confusing the GL driver.
We also currently guard against setting a EGL_NO_SURFACE as current
EGLSurface, but this shouldn't be a problem if we have a surfaceless
context. So we allow surface destruction under that condition.
https://bugzilla.gnome.org/show_bug.cgi?id=754667
If the user switches VTs in the middle of a page flip, the
page flip operation may fail with EACCES. page flipping will
work next time the VT becomes active, so we shouldn't disable
page flipping in that case.
https://bugzilla.gnome.org/show_bug.cgi?id=754540
If cogl fails to open the drm device, initialize gbm, or open the
egl display, then it closes the drm fd, uninitializes gbm, closes the
display and then calls _cogl_winsys_renderer_disconnect which does
most of those things again, on the, now deinitialized, members.
This commit removes the explicit failure handling in renderer_connect and
defers cleanup to disconnect.
https://bugzilla.gnome.org/show_bug.cgi?id=754540
gbm confusingly has two different format types, and cogl
is using the wrong one in some of its calls to gbm_surface_create
This commit fixes the calls that are wrong.
https://bugzilla.gnome.org/show_bug.cgi?id=754540
glGetIntegerv (GL_DEPTH_BITS, ...) and friends are deprecated in GL3; we
have to use glGetFramebufferAttachmentParameteriv() instead, like we do
for offscreen framebuffers.
Based on a patch by: Adel Gadllah <adel.gadllah@gmail.com>
Signed-off-by: Emmanuele Bassi <ebassi@gnome.org>
https://bugzilla.gnome.org/show_bug.cgi?id=753295
We want to be able to retrieve the XVisualInfo used when creating the
GL context under GLX and EGL-X11, so that we can use the visual before
we have an onscreen frame buffer.
Initialize variables; GCC does not always catch all cases where the
variables are used after being initialized, especially when it comes to
out parameters.
Some drivers ( like mgag200 ) don't yet support drmModePageFlip.
This commit forgoes waiting for vblank and flips right away
in those cases. That prevents the hardware from freezing up the screen,
but does mean there will be some visible tearing.
https://bugzilla.gnome.org/show_bug.cgi?id=746042
We can't just destroy and replace the EGL and gbm surfaces while
they are still in use i.e. while there is a pending flip. In fact, in
that case, we were calling gbm_surface_destroy() on a surface that
still had the front buffer locked and then, on the flip handler,
gbm_surface_release_buffer() for a buffer that didn't belong to the
new surface.
Instead, we still allocate new surfaces when requested but they only
replace the old ones on the next swap buffers when we're sure that the
previous flip has been handled and buffers properly released.
Currently the code queries the current msc then tries to approximate the
value of the next msc satisfing the modulus 2 for when to wait. This
introduces some instability as the msc may tick over during the
roundtrip leading to a 32ms wait instead of a 16ms wait. This happens
often enough to cause jerky animations, and affect gnome-shell-perf-tool.
A simpler solution is just use a single roundtrip by using WaitForMsc to
ask the driver to compute the next vblank itself.
Cc: Owen W. Taylor <otaylor@fishsoup.net>
Cc: Robert Bragg <robert@linux.intel.com>
Reviewed-by: Robert Bragg <robert@sixbynine.org>
Add cogl_texture_pixmap_x11_new_left() and
cogl_texture_pixmap_x11_new_right() (which takes the left texture
as an argument) for texture pixmap rendering with stereo content.
The underlying GLXPixmap is created using a stereo visual and shared
between the left and right textures.
Reviewed-by: Robert Bragg <robert.bragg@intel.com>
If we want to show quad-buffer stereo with Cogl, we need to pick an
appropriate fbconfig for creating the CoglOnscreen objects. Add
cogl_onscreen_template_set_stereo_enabled() to indicate whether
stereo support is needed.
Add cogl_framebuffer_get_stereo_mode() to see if a framebuffer was
created with stereo support.
Add cogl_framebuffer_get_stereo_mode() to pick whether to draw to
the left, right, or both buffers.
Reviewed-by: Robert Bragg <robert.bragg@intel.com>
An application might for whatever reason want to control a specific output
directly and have cogl only swap the other outputs if any. So add an api that
allows setting a crtc to be ignored.
https://bugzilla.gnome.org/show_bug.cgi?id=730536
The surfaceless context extension can be used to bind a context
without a surface. We can use this to avoid creating a dummy surface
when the CoglContext is first created. Otherwise we have to have the
dummy surface so that we can bind it before the first onscreen is
created.
The main awkward part of this patch is that theoretically according to
the GL and GLES spec if you first bind a context without a surface
then the default state for glDrawBuffers is GL_NONE instead of
GL_BACK. In practice Mesa doesn't seem to do this but we need to be
robust against a GL implementation that does. Therefore we track when
the CoglContext is first used with a CoglOnscreen and force the
glDrawBuffers state to be GL_BACK.
There is a further awkward part in that GLES2 doesn't actually have a
glDrawBuffers state but GLES3 does. GLES3 also defaults to GL_NONE in
this case so if GLES3 is available then we have to be sure to set the
state to GL_BACK. As far as I can tell that actually makes GLES3
incompatible with GLES2 because in theory if the application is not
aware of GLES3 then it should be able to assume the draw buffer is
always GL_BACK.
Reviewed-by: Robert Bragg <robert.bragg@intel.com>
(cherry picked from commit e5f28f1e75db9bdc4f2688f420a74f908f96cf76)
Conflicts:
cogl/winsys/cogl-winsys-egl-kms.c
cogl/winsys/cogl-winsys-egl-x11.c
Some features that were previously available as an extension in GLES2
are now in core in GLES3 so we should be able to specify that with the
gles_availability mask of COGL_EXT_BEGIN so that GL implementations
advertising GLES3 don't have to additionally advertise the extension
for us to take advantage of it.
Reviewed-by: Robert Bragg <robert.bragg@intel.com>
(cherry picked from commit 4d892cd97558da61ba526f947ac0555ebab632d2)
When a new CoglAtlasTexture tries to fit into an existing CoglAtlas
it should make sure the atlas stays valid while it expands.
https://bugzilla.gnome.org/show_bug.cgi?id=728064
Reviewed-by: Neil Roberts <neil@linux.intel.com>
(cherry picked from commit 2eec9758f67e9073371c2edd63379324849373c4)
This can happen when we dpms off the output or when login1 takes away
drm master status from our drm fd. In either case, we need to call
the swap notify handler so that the compositor dosn't get stuck waiting
for that notification. The compositor should stop repainting shortly in
both cases, as it's either going into dpms off mode or vt switching away.
https://bugzilla.gnome.org/show_bug.cgi?id=728979
Reviewed-by: Neil Roberts <neil@linux.intel.com>
This environment variable predates the reliable platform detection in mesa
and typically just causes crashes when the specified platform doesn't
match what's passed in. Aside from being unecessary and problematic
it also leaks into the GNOME session, preventing clients from
automatically detecting the wayland platform.
https://bugzilla.gnome.org/show_bug.cgi?id=728978
Reviewed-by: Neil Roberts <neil@linux.intel.com>
Prevent Cogl function names from being mangled when a C++ compiler is
being used by adding some missing COGL_{BEGIN,END}_DECLS guards.
https://bugzilla.gnome.org/show_bug.cgi?id=728628
Reviewed-by: Neil Roberts <neil@linux.intel.com>
Commit 1b2dd815 (Registers gtypes for all public objects and structs)
introduced GCCism's in its use of varargs, which broke the build of Cogl
on other non-GCC compilers, such as Visual Studio.
Define the COGL_GTYPE_DEFINE_BASE_CLASS and COGL_GTYPE_DEFINE_CLASS macros
using ISO-style varargs so that the build of Cogl can be fixed on non-GCC
compilers.
Reviewed-by: Neil Roberts <neil@linux.intel.com>
Remove #pragma directives that causes any applications that use Cogl to
link to the SDL libraries when Cogl was built with the SDL winsys. This is
mainly due to the availability of both SDL-1.x and SDL-2.x support in the
SDL winsys, where different libraries are linked for SDL-1.x and SDL-2.x.
To avoid having to link to the SDL/SDL2 libraries when the application code
is not directly using SDL/SDL2, define SDL_MAIN_HANDLED in the CFLAGS so
that SDL's wrapper main() implementation will not be used when the
application is being built.
Reviewed-by: Neil Roberts <neil@linux.intel.com>
(cherry picked from commit c3035912833eabe1f6dadbea23c78e595aac79dc)
In Lionel's work for supporting introspection better for Cogl, a number of
public symbols were added for Cogl and Cogl-Path, so add these symbols to
cogl.symbols and cogl-path.symbols so that they can be exported, which will
fix the build of the Cogl conformance test and the introspection files
for the Windows-based builds.
Reviewed-by: Neil Roberts <neil@linux.intel.com>
This macro is internal to gobject so using it risks breaking Cogl if
glib changes its API. Instead we just use its expansion. Note that
glib provides two expansions for this depending on the glib version
but this only uses the one for older versions.
Reviewed-by: Robert Bragg <robert.bragg@intel.com>
This adds much more comprehensive support for gobject-introspection
based bindings by registering all objects as fundamental types that
inherit from CoglObject, and all structs as boxed types.
Co-Author: Robert Bragg <robert@linux.intel.com>
Reviewed-by: Neil Roberts <neil@linux.intel.com>
Remove the symbols that are now in cogl-path (where cogl-path.symbols
already include), and add the symbols that were added to the Cogl API.
Also add internal symbols as required by cogl-path and cogl-pango.
Reviewed-by: Neil Roberts <neil@linux.intel.com>
The DriverCallback is a function that is defined by the Windows SDK 8.0+
headers, which was initially used for device driver development. The use
of DriverCallback would cause a clash, causing things to break when built
with newer Windows SDKs, so rename DriverCallback to CoglDriverCallback to
avoid this problem.
Reviewed-by: Neil Roberts <neil@linux.intel.com>
To help facilitate integration with third party frameworks this exposes
the EGL context and display to applications as well as the GLX context.
(Note that the GLX display is already available via
cogl_xlib_renderer_get_display())
This adds a new top-level <cogl/cogl-glx.h> header that needs to be
included explicitly to access the glx specific api.
Anyone using these apis will be responsible for checking that Cogl
is indeed using EGL or GLX by calling cogl_renderer_get_winsys_id()
This will enable GStreamer, for example, to be able to create a GL
context that shares resources with Cogl's context.
https://bugzilla.gnome.org/show_bug.cgi?id=724992
Reviewed-by: Neil Roberts <neil@linux.intel.com>
This splits out the GLeglImageOES define in cogl-egl.h into a private
cogl-egl-private.h header and updates the guards in cogl-egl.h to be
consistent with other top-level headers where we need to be careful
about how __COGL_H_INSIDE__ is defined and undefined, esp when the
gobject introspection scanner is running.
Reviewed-by: Neil Roberts <neil@linux.intel.com>
This ensures we use EGLNativeWindowType and EGLNativeDisplayType
everywhere instead. The previous names come from EGL 1.2 but it seems
reasonable to require more recent EGL versions. If someone wanted to add
compatibility for EGL 1.2 later it would be straightforward to define
the new names to the old.
Reviewed-by: Neil Roberts <neil@linux.intel.com>
SDL2 supports selecting between full OpenGL or OpenGL ES 1/2 but our
selection code was written before SDL 2.0 was officially released and
since then a new SDL_GL_CONTEXT_PROFILE_MASK attribute was added and
we have to explicitly set the SDL_GL_CONTEXT_MINOR_VERSION attribute.
Reviewed-by: Neil Roberts <neil@linux.intel.com>
This adds a new COGL_FEATURE_ID_BUFFER_AGE feature id that can be used
to determine if cogl_onscreen_get_buffer_age() will ever return an age
other than 0. This should be used instead of querying the winsys feature
via cogl_clutter_winsys_has_feature().
Reviewed-by: Neil Roberts <neil@linux.intel.com>
We have an #ifdef EGL_WL_bind_wayland_display guard in
cogl-winsys-egl-feature-functions.h to avoid referencing wayland types
when the EGL header doesn't know about them, but somehow this guard also
ended up around the KHR_create_context and EXT_buffer age features too
even though they aren't wayland specific.
Reviewed-by: Neil Roberts <neil@linux.intel.com>
This winsys feature flag is exposed via the deprecated
cogl_clutter_winsys_has_feature function and Clutter is curently
relying on it. Previously the EGL winsys was only setting the internal
COGL_EGL_WINSYS_FEATURE_BUFFER_AGE flag and there was no mapping to
the public flag. Therefore the feature would only be used on GLX. This
patch just adds the mapping.
Reviewed-by: Robert Bragg <robert@linux.intel.com>
(cherry picked from commit 8418e98b2b1b25515a961ad1bb9f0c4770d6eb1d)
Reviewed-by: Neil Roberts <neil@linux.intel.com>
(cherry picked from commit 7bc7ea4cb5e8134a3aeed9615477f4152b558509)
Conflicts:
cogl/winsys/cogl-winsys-egl-kms.c
Instead of spinning forever, do a roundtrip, which guarantees that the
global messages have been sent by the time we read the sync message.
If the proper globals aren't initialized yet, error out immediately. This
does mean that users can't use CoglOnscreen with foreign custom surface
types without xdg_shell, but when a use case comes for this, we'll
investigate then...
Reviewed-by: Neil Roberts <neil@linux.intel.com>
(cherry picked from commit af9057d35f331e2c9509958fb40627917c477b80)
Since the Cogl 1.18 branch is actively maintained in parallel with the
master branch; this is a counter part to commit 1b83ef938fc16b which
re-licensed the master branch to use the MIT license.
This re-licensing is a follow up to the proposal that was sent to the
Cogl mailing list:
http://lists.freedesktop.org/archives/cogl/2013-December/001465.html
Note: there was a copyright assignment policy in place for Clutter (and
therefore Cogl which was part of Clutter at the time) until the 11th of
June 2010 and so we only checked the details after that point (commit
0bbf50f905)
For each file, authors were identified via this Git command:
$ git blame -p -C -C -C20 -M -M10 0bbf50f905..HEAD
We received blanket approvals for re-licensing all Red Hat and Collabora
contributions which reduced how many people needed to be contacted
individually:
- http://lists.freedesktop.org/archives/cogl/2013-December/001470.html
- http://lists.freedesktop.org/archives/cogl/2014-January/001536.html
Individual approval requests were sent to all the other identified authors
who all confirmed the re-license on the Cogl mailinglist:
http://lists.freedesktop.org/archives/cogl/2014-January
As well as updating the copyright header in all sources files, the
COPYING file has been updated to reflect the license change and also
document the other licenses used in Cogl such as the SGI Free Software
License B, version 2.0 and the 3-clause BSD license.
This patch was not simply cherry-picked from master; but the same
methodology was used to check the source files.
Not doing so leads to the following error, if stddef.h is not included
indirectly through EGL headers:
| libdrm/drm.h:132:2: error: unknown type name 'size_t'
| size_t name_len; /**< Length of name buffer */
Signed-off-by: Andreas Oberritter <obi@saftware.de>
Reviewed-by: Robert Bragg <robert@linux.intel.com>
(cherry picked from commit 55c82476a93366a3e7d1a2537fccc3a7aab87c66)
The _cogl_egl_texture_2d_new_from_image function has a CoglError
argument which implies that it is unlike the other texture
constructors and returns errors immediately rather than having a
delayed-allocation mechanism. cogl_wayland_texture_2d_new_from_buffer
which calls it is also like this. We can't rely on delayed-allocation
semantics for this without changing the applications because the
texture needs to be allocated before the corresponding EGLImage is
destroyed. This patch just makes it immediately allocate.
A better patch might be to remove the error argument to make it
obvious that there are delayed-allocation semantics and then fix all
of the applications.
This was breaking Cogland and Mutter.
Reviewed-by: Robert Bragg <robert@linux.intel.com>
(cherry picked from commit 0206c03d54823b2f6cbb2aa420d07a4db9bcd8a3)
The previous implementation was dereferencing the sample pointer in
order to get the offset to subtract from the member pointer. The
resulting value is then only used to get a pointer to the member in
order to calculate the offset so it doesn't actually read from the
memory location and shouldn't cause any problems. However this is
probably technically invalid and could have undefined behaviour. It
looks like clang takes advantage of this undefined behaviour and
doesn't actually offset the pointer. It also generates a warning when
it does this.
This patch splits the _cogl_container_of macro into two
implementations. Previously the macro was always used in the list
iterator macros like this:
SomeType *sample = _cogl_container_of(list_node, sample, link)
Instead of doing that there is now a new macro called
_cogl_list_set_iterator which explicitly assigns to the sample pointer
with an initial value before assigning to it again with the real
offset. This redundant initialisation gets optimised out by compiler.
The second macro is still called _cogl_container_of but instead of
taking a sample pointer it just directly takes the type name. That way
it can use the standard offsetof macro.
https://bugzilla.gnome.org/show_bug.cgi?id=723530
Reviewed-by: Robert Bragg <robert@linux.intel.com>
(cherry picked from commit 1efed1e0a2bce706eb4901979ed4e717bb13e4e2)
The declaration of INTEL_swap_event was treating winsys features as
if they were a bitfield, but they aren't. The end result was that
instead of reporting two features when INTEL_swap_event is present,
we report none.
https://bugzilla.gnome.org/show_bug.cgi?id=719741
Reviewed-by: Robert Bragg <robert@linux.intel.com>
Since 248a76f5eac7e5ae4fb45208577f9a55360812a7 cogl.h can no longer be
included in internal source files so the WGL winsys was no longer
compiling.
Reviewed-by: Robert Bragg <robert@linux.intel.com>
(cherry picked from commit 91af97a2a27ab5ad3e7eaabebd03503b685d4d42)
This adds COGL_PIXEL_FORMAT_RG_88 and COGL_TEXTURE_COMPONENTS_RG in
order to support two-component textures. The RG components for a
texture is only supported if COGL_FEATURE_ID_TEXTURE_RG is advertised.
This is only available on GL 3, GL 2 with the GL_ARB_texture_rg
extension or GLES with the GL_EXT_texture_rg extension. The RG pixel
format is always supported for images because Cogl can easily do the
conversion if an application uses this format to upload to a texture
with a different format.
If an application tries to create an RG texture when the feature isn't
supported then it will raise an error when the texture is allocated.
https://bugzilla.gnome.org/show_bug.cgi?id=712830
Reviewed-by: Robert Bragg <robert@linux.intel.com>
(cherry picked from commit 568677ab3bcb62ababad1623be0d6b9b117d0a26)
Conflicts:
cogl/cogl-bitmap-packing.h
cogl/cogl-types.h
cogl/driver/gl/gl/cogl-driver-gl.c
tests/conform/test-read-texture-formats.c
tests/conform/test-write-texture-formats.c
The following changes are made to the documentation for CoglTexture:
• The description of the default value for the components property is
changed to say that it is always RGBA for textures created by the
‘_with_size’ textures. Previously it said that the default is based
on the pixel format used the first time data is set on the texture,
but this is only true if the data is set using a constructor.
• Added documentation for the CoglTextureComponents enum.
• Changed it to say that it _specifies_ what components are required
for sampling rather than determinging [sic] them.
• Added ‘Since: 1.18’ to
cogl_texture_{set,get}_{components,premultiplied}
• Changed the since tag for CoglTextureError from 2.0 to 1.8.
• Added documentation for COGL_TEXTURE_ERROR_{FORMAT,TYPE}.
• Added the following to the cogl2-sections.txt file:
COGL_TEXTURE_ERROR
CoglTextureError
cogl_texture_allocate
cogl_texture_set_components
cogl_texture_get_components
cogl_texture_set_premultiplied
cogl_texture_get_premultiplied
Reviewed-by: Robert Bragg <robert@linux.intel.com>
(cherry picked from commit 2f12c4329c519fa14b927b2dcd708dddcc903c32)
Previously when a pipeline is added to the cache it would never be
removed. If the application is generating a lot of unique pipelines
this can end up effectively leaking a large number of resources
including the GL program objects. Arguably this isn't really a problem
because if the application is generating that many unique pipelines
then it is doing something wrong anyway. It also implies that it will
be recompiling shaders very often so the cache leaking will likely be
the least of the problems.
This patch makes it keep track of which pipelines in the cache are in
use. The cache now returns a struct representing the entry instead of
directly returning the pipeline. This entry contains a usage counter
which the pipeline backends can use to mark when there is a pipeline
alive that is using the cache entry. When the hash table decides that
it's a good time to prune some entries, it will make a list of all of
the pipelines that are not in use and then remove the least recently
used half of the pipelines. That way it is less likely to remove
pipelines that the application is actually regenerating often even if
they aren't in use all of the time.
When the cache is pruned the hash table makes a note of how small the
cache could be if it removed all of the unused pipelines. The hash
table starts pruning when there are more entries than twice this
minimum expected size. The idea is that if that case it hit then the
hash table is more than half full of useless pipelines so the
application is generating lots of redundant pipelines and it is a good
time to remove them.
Reviewed-by: Robert Bragg <robert@linux.intel.com>
(cherry picked from commit c21aac22992bb7fef5a8d0913130b8245e67f2eb)
Conflicts:
cogl/driver/gl/cogl-pipeline-fragend-glsl.c
cogl/driver/gl/cogl-pipeline-progend-glsl.c
cogl/driver/gl/cogl-pipeline-vertend-glsl.c
cogl/driver/gl/gl/cogl-pipeline-fragend-arbfp.c
This fixes the cogl_texture_get_components() prototype to have a return
type of CoglTextureComponents instead of CoglBool which was probably a
copy and paste error.
(cherry picked from commit 55b09f8a939db71ee5ff41afa0ed08cbe937a4ec)
This updates the cogl_texture_rectangle_new_with_size() api in line with
master to be consistent with other texture constructors. This removes
the internal_format and error arguments and allows the texture to be
allocated lazily which means the texture can be configured with apis
like cogl_texture_set_components() and cogl_texture_set_premultiplied()
before it is allocated.
Reviewed-by: Neil Roberts <neil@linux.intel.com>
test-path for example uses COGL_ENABLE_EXPERIMENTAL_2_0_API to access
the 2.0 CoglPath api but also uses deprecated framebuffer api such as
cogl_push/pop_framebuffer. Similarly clutter-backend.c builds with
COGL_ENABLE_EXPERIMENTAL_2_0_API and uses cogl_set_framebuffer().
Reviewed-by: Neil Roberts <neil@linux.intel.com>
This moves the framebuffer stack apis out of cogl-framebuffer.c into
cogl/deprecated/cogl-framebuffer-deprecated.c so cogl-framebuffer.c is
more in-line with the master branch to ease cherry picking patches.
Reviewed-by: Neil Roberts <neil@linux.intel.com>
This moves all of the automagic texture constructor prototypes from
cogl-texture.h into a new deprecated/cogl-auto-texture.h file. This also
moves cogl_texture_new_from_sub_texture() into
deprecated/cogl-auto-texture.c
Reviewed-by: Neil Roberts <neil@linux.intel.com>
Texture allocation is now consistently handled lazily such that the
internal format can now be controlled using
cogl_texture_set_components() and cogl_texture_set_premultiplied()
before allocating the texture with cogl_texture_allocate(). This means
that the internal_format arguments to texture constructors are now
redundant and since most of the texture constructors now can't ever fail
the error arguments are also redundant. This now means we no longer
use CoglPixelFormat in the public api for describing the internal format
of textures which had been bad solution originally due to how specific
CoglPixelFormat is which is missleading when we don't support such
explicit control over the internal format.
Reviewed-by: Neil Roberts <neil@linux.intel.com>
(cherry picked from commit 99a53c82e9ab0a1e5ee35941bf83dc334b1fbe87)
Note: there are numerous API changes for functions currently marked
as 'unstable' which we don't think are in use by anyone depending on
a stable 1.x api. Compared to the original patch though this avoids
changing the cogl_texture_rectangle_new_with_size() api which we know
is used by Mutter.
This introduces the internal idea of texture loaders that track the
state for loading and allocating a texture. This defers a lot more work
until the texture is allocated.
There are several intentions to this change:
- provides a means for extending how textures are allocated without
requiring all the parameters to be supplied in a single _texture_new()
function call.
- allow us to remove the internal_format argument from all
_texture_new() apis since using CoglPixelFormat is bad way of
expressing the internal format constraints because it is too specific.
For now the internal_format arguments haven't actually been removed
but this patch does introduce replacement apis for controlling the
internal format:
cogl_texture_set_components() lets you specify what components your
texture needs when it is allocated.
cogl_texture_set_premultiplied() lets you specify whether a texture
data should be interpreted as premultiplied or not.
- Enable us to support asynchronous texture loading + allocation in the
future.
Of note, the _new_from_data() texture constructors all continue to
allocate textures immediately so that existing code doesn't need to be
adapted to manage the lifetime of the data being uploaded.
Reviewed-by: Neil Roberts <neil@linux.intel.com>
(cherry picked from commit 6a83de9ef4210f380a31f410797447b365a8d02c)
Note: Compared to the original patch, the ->premultipled state for
textures isn't forced to be %TRUE in _cogl_texture_init since that
effectively ignores the users explicitly given internal_format which was
a mistake and on master that change should have been made in the patch
that followed. The gtk-doc comments for cogl_texture_set_premultiplied()
and cogl_texture_set_components() have also been updated in-line with
this fix.
When reading a texture back by first wrapping it as an offscreen
framebuffer and using _read_pixels_into_bitmap() we now make sure the
offscreen framebuffer has an internal format that matches the
meta-texture being read not that of the current sub-texture being
iterated. In the case of atlas textures the subtexture is a shared
texture whose format doesn't reflect the premultipled alpha status of
individual atlas-textures, nor whether the alpha component is valid.
Reviewed-by: Neil Roberts <neil@linux.intel.com>
(cherry picked from commit 6ee425d4f10acd8b008a2c17e5c701fc1d850f59)
CoglPixelFormat is not a good way of describing the internal
format of a texture because it's too specific given that we don't
actually have exact knowledge of the internal format used by the driver.
This makes cogl_texture_get_format private and in the future we'll
provide a better way of querying the channels and their precision.
Reviewed-by: Neil Roberts <neil@linux.intel.com>
(cherry picked from commit ffde82981f22bd0185a7f33e1e6e1479f4c295b8)
Note: Since we can't break API compatibility on the 1.x branch this adds
a cogl/deprecated/cogl-texture-deprecated.c file with a
cogl_texture_get_format() wrapper around the private api. This also
moves the cogl_texture_get_rowstride() and cogl_texture_ref/unref()
functions that were previously deprecated into cogl-texture-deprecated.c
This defers checking the internal format and whether accelerated
migration is supported until allocating the texture.
Reviewed-by: Neil Roberts <neil@linux.intel.com>
(cherry picked from commit 83b05cbe3969789bc3ec78480c0937a6722efbf1)
Instead of throwing a CoglError exception if an application tries to
allocate a zero size atlas texture this make that a programmer error
instead.
Reviewed-by: Neil Roberts <neil@linux.intel.com>
(cherry picked from commit d3eaeedc86d408669b81d6c43ef2b0ab9d859c85)
The plan is to defer a lot more work in creating a texture until
allocation time. This means that for some texture backends we might not
know until after allocation whether the texture is sliced or can support
hardware repeating. This makes sure we trigger an allocation if either
of these are queried.
Reviewed-by: Neil Roberts <neil@linux.intel.com>
(cherry picked from commit 4868582812dbcd5125495b312d858f751fc31e9d)
The plan is to defer a lot more work in creating a texture until
allocation time. This means we wont be able to assume that all textures
being used to render must have already been allocated when data was
specified.
The latest point at which we will generally require a texture to be
allocated will be when we need to know the underlying GL handle for a
texture and so this updates cogl_texture_get_gl_texture() to ensure the
texture is allocated.
Reviewed-by: Neil Roberts <neil@linux.intel.com>
(cherry picked from commit 59f6fefc37524f492512a71b831760a218d9bb95)
The plan is to defer more of the work for creating a texture until
allocation time, but that means we won't be able to always assume
we can query the size of a texture when creating an offscreen
framebuffer from a texture (consider for example using
_texture_new_from_file() where the size isn't known until the file has
been loaded). This defers needing to know the size of the texture
underlying an offscreen framebuffer until calling
cogl_framebuffer_allocate().
Reviewed-by: Neil Roberts <neil@linux.intel.com>
(cherry picked from commit 9688e7dc1eeae3144729dfd4a4bf409620346bf4)
This ensures framebuffers are implicitly allocated when querying the
width, height or viewport width/height if the framebuffer's size is
currently unknown. The plan is to allow texture backends to defer
calculating the size of textures until they are allocated which in turn
means we won't know the size of offscreen framebuffers until the texture
has been allocated. Potentially we could be more specific about this in
the future and only ensure the texture is allocated, but for now it will
be simplest to just ensure the framebuffer is allocated.
Note: in the case of onscreen buffers which are always initialized with
a requested size we are careful to avoid triggering an allocation when
this is queried otherwise we will see recursion when the winsys code
queries the requested size during allocation.
Reviewed-by: Neil Roberts <neil@linux.intel.com>
(cherry picked from commit f4b612f1b75e043f1852b9a32368cc37ab89308b)
Since we are planning on deferring more texture allocation work this
makes sure we don't query whether a texture is sliced until we know it
has been allocated.
Reviewed-by: Neil Roberts <neil@linux.intel.com>
(cherry picked from commit b742638a1ce581f5a2c9f15907361c3b0c1b178c)
This removes cogl_framebuffer_get_color_format() since the actual
internal format isn't strictly controlled by us. CoglFramebuffer::format
has been renamed to ::internal_format to make it clearer that it only
really represents the premultiplication status.
The plan is to make most of the work involved in creating a texture
happen lazily when allocating so this patch also changes
_cogl_framebuffer_init() to not take a format argument anymore since we
won't know the format of offscreen framebuffers until the framebuffer is
allocated, after the corresponding texture has been allocated. In the
case of offscreen framebuffers we now update the framebuffer
internal_format during allocation.
Reviewed-by: Neil Roberts <neil@linux.intel.com>
(cherry picked from commit 8cc9e1c8bd2fac8b2a95087249c23c952d5e379f)
Note: Since we can't break API compatibility on the 1.x branch this
actually keeps the cogl_framebuffer_get_color_format() api but moves it
into a new deprecated/cogl-framebuffer-deprecated.c file and it now
returns the newly name ::internal_format.
The bug that prevented MESA_copy_sub_buffer to work for swrast /
llvmpipe got fixed in mesa 10.1 git so enable it for mesa 10.1+.
https://bugzilla.gnome.org/show_bug.cgi?id=721450
When landing the patch, it was tweaked to #include "cogl-version.h" to
avoid a compiler warning about COGL_VERSION_ENCODE being implicitly
defined. -- Robert Bragg
Reviewed-by: Robert Bragg <robert@linux.intel.com>
(cherry picked from commit e7e216b1d3d151acf3fed619bd759692a989b4b4)
Since we now have more time to ensure that Clutter is updated to check
for the now separate cogl-path package as part of its build
configuration we are now making the package split, in line with Cogl
master.
Reviewed-by: Neil Roberts <neil@linux.intel.com>
This makes it so that cogl-sdl.h is a top-level header no longer
automatically included by cogl.h. This avoids lots of warnings building
the conformance tests and examples due to SDL.h warning when
__STRICT_ANSI__ isn't defined.
Reviewed-by: Neil Roberts <neil@linux.intel.com>
(cherry picked from commit f7536985437dc85c26b33d1bbe1b7f3d4b32476a)
This means that we can't cache the journal read_pixels optimization.
https://bugzilla.gnome.org/show_bug.cgi?id=719582
Reviewed-by: Neil Roberts <neil@linux.intel.com>
Reviewed-by: Robert Bragg <robert@linux.intel.com>
(cherry picked from commit 550bae22d20c8d6d7cf1d090faa9c91619594077)
This reverts commit bc41489336.
The reason this was causing problems for Clutter is that it defines
COGL_ENABLE_EXPERIMENTAL_2_0_API which is meant to cause the Cogl
headers not to declare the deprecated API. The reverted patch moved
some additional clipping API to a deprecated header which was
previously being used by Clutter. Clutter was still successfully
compiling but with some warnings for the missing function
declarations. However when the binary is run the clipping would get
completely messed up because it would assume all of the arguments to
the functions are integers instead of floats and the wrong values
would be passed.
Clutter now has commit to make it use the 2.0 API instead of the
deprecated functions so the revert is no longer necessary.
https://git.gnome.org/browse/clutter/commit?id=705640367a5c2ae21405806bfa
Reviewed-by: Robert Bragg <robert@linux.intel.com>
When projecting the bounding rectangle of a primitive it was using the
modelview matrix twice instead of the modelview and projection
matrices so it was coming out with garbage.
Reviewed-by: Robert Bragg <robert@linux.intel.com>
(cherry picked from commit 7e1f05c84013bb91248d691091df00f4f634c6cf)
This reverts commit ae9cd7ca01.
Pushing this for now so we can get gnome-shell working again without
memory corruption. Let's push a proper fix later for everybody.
This was added in 361bd516f3 late during the 1.10 cycle to
contain experimental functions that we should never have made public.
The plan was to remove them once we started working on 1.12 but it
looks like we never got around to doing that. Better late than never!
The header for the file was already removed in 7365c3aa77.
Reviewed-by: Robert Bragg <robert@linux.intel.com>
There used to be a function called cogl_clip_stack_save in the public
API which was used when temporarily switching to an offscreen buffer
to save the clip state. This is no longer necessary because each
framebuffer has its own clip stack anyway so the function was removed
in master. However the code to maintain the stack of stacks was
retained. This patch removes it in an effort to simplify the code.
On the 1.18 branch this function is deprecated and the documentation
says that it does nothing. However that is incorrect because it does
actually the push clip stack. I think it would be safe to backport
this patch to the 1.18 branch and actually make it do nothing like it
is documented to do.
https://bugzilla.gnome.org/show_bug.cgi?id=719546
(cherry picked from commit 8655027fdcf03b02fcbbb02d179a0a88ed79c5b3)
This patch has some extra changes while backporting to the 1.18
branch. Here the cogl-clip-state file still contained some deprecated
functions. Instead of deleting the file completely it has been moved
to the deprecated folder. The declarations for this functions have
been moved from cogl1-context.h to a new deprecated/cogl-clip-state.h
header.
Conflicts:
cogl/Makefile.am
cogl/cogl-clip-state.c
Reviewed-by: Robert Bragg <robert@linux.intel.com>
Adds cogl_wayland_texture_set_region_from_shm_buffer which is a
convenience wrapper around cogl_texture_set_region but it uses the
correct format to copy the data from a Wayland SHM buffer. This will
typically be used by compositors to update the texture for a surface
when an SHM buffer is attached. The ordering of the arguments is based
on cogl_texture_set_region_from_bitmap.
Based on a patch by Jasper St. Pierre.
Reviewed-by: Robert Bragg <robert@linux.intel.com>
(cherry picked from commit c76c1d136d2cac7f3d1331a4d1dc0dd0f06e812c)
Conflicts:
examples/cogland.c
This patch was accidentally added before it had any review and without
first going through master. Master now has a replacement patch with
some modifications. That will be cherry-picked to the 1.18 branch in a
subsequent commit.
This reverts commit af480a2b8b.
Previously the private feature flags were stored in an enum and we
already had 31 flags. Adding the 32nd flag would presumably make it
add -2³¹ as one of the values which might cause problems. To avoid
this we'll just use an fixed-size array of longs and use indices for
the enum values like we do for the public features.
A slight complication with this is in the CoglDriverDescription where
we were previously using a static intialised value to describe the set
of features that the driver supports. We can't easily do this with the
flags array so instead the features are stored in a fixed-size array
of indices.
Reviewed-by: Robert Bragg <robert@linux.intel.com>
(cherry picked from commit d94cb984e3c93630f3c2e6e3be9d189672aa20f3)
Conflicts:
cogl/cogl-context-private.h
cogl/cogl-context.c
cogl/cogl-private.h
cogl/cogl-renderer.c
cogl/driver/gl/cogl-pipeline-opengl.c
cogl/driver/gl/gl/cogl-driver-gl.c
cogl/driver/gl/gl/cogl-pipeline-progend-fixed-arbfp.c
cogl/driver/gl/gles/cogl-driver-gles.c
cogl/driver/nop/cogl-driver-nop.c
This fixes the build with --enable-introspection. I'm not sure why
g-ir-scanner seems to parse all public headers in isolation instead of
being able take a more limited list of top-level public headers and
automatically parse all necessary #include directives but this means we
have to special case how we define and undefine __COGL_H_INSIDE__ to
subvert the guards we have in place for detecting misuse of the headers.
Reviewed-by: Neil Roberts <neil@linux.intel.com>
(cherry picked from commit e0b2255876c1cf11d124d5ae37cbe9a6e43777f1)
This declares the interface types CoglFramebuffer, CoglBuffer,
CoglTexture, CoglMetaTexture and CoglPrimitiveTexture as void when
including the public cogl.h header so that users don't have to use lots
of C type casts between instance types and interface types.
This also removes all of the COGL_XYZ() type cast macros since they do
nothing more than compile time type casting but it's less readable if
you haven't seen that coding pattern before.
Unlike with gobject based apis that use per-type macros for casting and
performing runtime type checking we instead prefer to do our runtime
type checking internally within the front-end public apis when objects
are passed into Cogl. This greatly reduces the verbosity for users of
the api and may help reduce the chance of excessive runtime type
checking that can sometimes be a problem.
(cherry picked from commit 248a76f5eac7e5ae4fb45208577f9a55360812a7)
Since we can't break the 1.x api this version of the patch actually
defines compatible NOP macros within deprecated/cogl-type-casts.h
This patch doesn't look right because now nothing will ever set
clear_clip_dirty = TRUE. Presumably that would mean that if a
rectangle is drawn and then the journal is flushed before the
framebuffer is read, then it would think it could return the clear
color even though it shouldn't.
Perhaps a better approach would be to make a second version of
_cogl_framebuffer_mark_mid_scene that doesn't set the clear_clip_dirty
flag and call that from the journal instead. As this patch was pushed
without review and without first going into the master branch I think
it makes sense to just revert it and apply a new version to master.
This reverts commit 3eb63f67a3.
Leaving the clip bounds untouched means that it will retain the stale value
of whatever it was when we last had a clip; reset it so that it contains the
full framebuffer contents instead.
https://bugzilla.gnome.org/show_bug.cgi?id=712562
Add framebuffer methods cogl_framebuffer_[gs]et_depth_write_enabled()
and backend bits to pass the state on to glDepthMask().
This allows us to enable or disable depth writing per-framebuffer, which
if disabled saves us some work in glClear(). When rendering, the flag
is combined with the pipeline's depth writing flag using a logical AND.
Depth writing is enabled by default.
https://bugzilla.gnome.org/show_bug.cgi?id=709827
Reviewed-by: Robert Bragg <robert@linux.intel.com>
(cherry picked from commit 71406438c5357eb4e0ef03e940c5456a536602a0)
Depending on what version of Mesa you have then eglQueryWaylandBuffer
may take a wl_buffer or wl_resource argument and the EGL header will
only forward declare the corresponding type.
The use of wl_buffer has been deprecated and so internally we assume
that eglQueryWaylandBuffer takes a wl_resource but for compatibility we
forward declare wl_resource in case we are building with EGL headers
that still use wl_buffer.
https://bugzilla.gnome.org/show_bug.cgi?id=710926
Reviewed-by: Neil Roberts <neil@linux.intel.com>
(cherry picked from commit 9bd1ee544667cfe7ecae479ec7f778446dd8f326)
cogl_is_atlas_texture is supposed to be exported from the DLL/.so, so
update the cogl.symbols file to ensure this.
Reviewed-by: Robert Bragg <robert@linux.intel.com>
(cherry picked from commit 13e037f096de5742db769500b4c0018249d8f8e4)
This makes cogl_framebuffer_set_color_mask immediately bail out if the
given mask equals the framebuffer's current mask, since the cost of
flushing the journal and flushing the gl state will hugely outweigh the
cost of the check.
Reviewed-by: Neil Roberts <neil@linux.intel.com>
(cherry picked from commit 925174d99df7f1f4b11098e748bcc23eaa396a21)
This updates the definition of _COGL_STATIC_ASSERT to just use
_Static_assert if available or be NOP if not. We no longer worry about
supporting static assertions with older compilers. This fixes some
verbose warnings that newer compilers were giving with the old typedef
based static assertion method.
Reviewed-by: Neil Roberts <neil@linux.intel.com>
(cherry picked from commit 645e3607ea7f210d6dcb9d217204790051de7c82)
When a pipeline is notified of a change we now make sure to notify all
progends of that change not just the progend directly associated with
that pipeline. A pipeline can have private state associated with it from
multiple progends because descendants will always try and cache state on
ancestors to maximize the chance that the state can later be re-used.
Descendants may be using different progends than the ancestors that they
cache state with.
Reviewed-by: Neil Roberts <neil@linux.intel.com>
(cherry picked from commit 873939a18934185fb3c9c84c373cb86d1278add7)
This avoids including wayland-server.h in cogl-display-private.h which
avoid lots of compile time warnings that wl_buffer is deprecated. The
problem is that wl_buffer is also exposed in the client side headers and
isn't deprecated for clients. If we end up including the client and
server headers in the same compilation unit we can get conflicting
definitions.
Reviewed-by: Neil Roberts <neil@linux.intel.com>
(cherry picked from commit 60fcd9c87cf5d8ae8c41134217ee0e1fa2fbd46e)
wl_buffer has been deprecated in the server API and instead
compositors should be directly passing the wl_resource pointer to
eglQueryWaylandBuffer.
Reviewed-by: Robert Bragg <robert@linux.intel.com>
(cherry picked from commit f13278bcf3f1475b7afc7d55a5218f409d119658)
Commit 50d1285b updated the wl_shm enum values but left
one out. Update it to fix the build on big-endian.
https://bugzilla.gnome.org/show_bug.cgi?id=710135
Reviewed-by: Neil Roberts <neil@linux.intel.com>
(cherry picked from commit 9246286846d0428b03e646b2f5ec14f0eff4edc6)
This makes a start on clearly factoring the deprecated code of core Cogl
into a deprecated/ directory. Ideally we want to get to the point where
all code here can be re-worked in terms of the public 2.0 api so that it
can be kept indefinitely for cogl 1.x api compatibility without
cluttering the core code base itself. If we can do this then we can
avoid maintaining the Cogl 1.x branches in parallel with master which
would reduce the maintenance effort.
Commit 7b25c8f5ca mistakenly added a reference to a
COGL_GTYPE_DEFINE_CLASS() macro that does not yet exist so this patch
removes it.
Reviewed-by: Neil Roberts <neil@linux.intel.com>
When running in a purely swrast environment (such as with
LIBGL_ALWAYS_SOFTWARE), the extension is not exposed by mesa,
but wayland is still possible with wl_shm.
https://bugzilla.gnome.org/show_bug.cgi?id=704750
Reviewed-by: Neil Roberts <neil@linux.intel.com>
(cherry picked from commit 8d4e4b0e8062708cece4d4c929abccc492ee21cc)
