This function returns a string of the boxed value considering type, size
and count; and adds a name.
e.g:
vec2 scale = vec2(1.0000, 1.0000)
Also handle NULL cases on _cogl_boxed_value_equal.
This will be used by the next commit.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3965>
Use _cogl_boxed_value_destroy to free the correspondent array instead of
free, which was only freeing float_array.
Add a new func _cogl_boxed_value_array_alloc to allocate the
corresponding array considering the type.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3965>
_cogl_boxed_value_transpose is only used for the matrix type.
Now is named _cogl_boxed_value_copy_transposed_value.
Gets the transposed value considering count (to store in array type or not).
The caller doesn't have to worry about count anymore.
Instead of calling memcpy, add function _cogl_boxed_value_copy_value
which copies the value to the corresponding boxed value property
considering type and count.
The caller doesn't have to worry about type and count anymore.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3965>
There are three array properties, considering type:
1. float *float_array
2. int *int_array
3. void *array
Drop using array. This was inteded to be used when type is matrix and
count > 1, however some functions use it and others use
float_array. Fix this using always float_array, this starts to make all funcs
consistent handling the properties.
There's a mem leak when destroying the boxed value, only freeing the array
prop. Free the corresponding array considering the boxed value type to fix it.
_cogl_boxed_value_set_x func is still inconsistent, the next commits
will solve it.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3965>
Because for `COGL_DRIVER_GL3`, `_cogl_context_get_gl_extensions` needs to
know that the GL version *really* is >= 3.0 before it calls `glGetStringi`
which didn't exist prior to GL 3.0 or ES 3.0.
This was causing crashes on Xilinx Mali implementations that only support
ES 2.0 (hence `glGetStringi` == NULL), but were being forced to call
that function before the GL version check which should tell you the
function isn't supported.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4019>
GLES 2.0 does not have RGB8 and RGBA8 as sized internal formats. There
is OES_rgb8_rgba8 which adds RGB8 and RGBA8 but only for
RenderbufferStorageOES and not for TexImage2D which I wrongly assumed.
It seems like there is currently no GLES2 extension which adds RGB8 and
RGBA8 to TexImage2D so we have no choice but to fall back to unsized
internal formats in those cases as long as we don't want to drop GLES2
support.
This should be fine in practice and we should get our 8bpc textures.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3680
Fixes: 7f943613a8 ("cogl: Use sized internal renderable formats")
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4036>
When !3952 introduced the new tracing macros, they were only defined in
the HAVE_PROFILER case, causing builds without profiler support to fail.
Also it introduced an unconditional call to cogl_is_tracing_enabled()
which is not available without HAVE_PROFILER.
Fixes: 777c63507 ("cogl/trace: Allow defining and setting sysprof trace counters")
Fixes: 322ac42a6 ("stage-impl: Trace the damage region")
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3991>
As GNOME Shell always sets that to FALSE anyways
This does not drop the separate caching whether the mipmapping is
disabled or not, in case shell wants to make use of that in the future
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3962>
Using GL_BGRA8_EXT as internalformat for TexSubImage2D was not allowed
in the EXT_texture_format_BGRA8888 extension. This changed recently:
https://registry.khronos.org/OpenGL/extensions/EXT/EXT_texture_format_BGRA8888.txt
1.4, 23/06/2024 Erik Faye-Lund: Add GL_BGRA8_EXT for ES 2.0 and later.
Mesa already supports this which is why 7f943613a8 ("cogl: Use sized
internal renderable formats") worked as intended. Technically spec
compliant and our CI had an up-to-date driver.
So while this is no bug, it's still not great because older drivers will
generate GL errors. This commit changes this specific format back to an
unsized internal format which means we could, in theory, get less than
8bpc framebuffers.
We can try to revert this commit when newer driver versions have
propagated far enough.
Fixes: 7f943613a8 ("cogl: Use sized internal renderable formats")
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3954>
There is one define for the format (GL_BGRA_EXT) and one for the
internal format (GL_BGRA8_EXT). Use them appropriately.
This also adds defines to consistenly not use the _EXT postfix.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3914>
The opaque fp16 Cogl format variants need a required format that is
already premultiplied whereas the fp16 formats with an alpha channel can
be either straight or premult.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3914>
We still use GLSL 100 syntax which means `varying`, `attribute` and
`gl_FragColor` but GLSL 140 wants us to use `in` and `out`. This
provides some simple `#define`s to make it still look like the GLSL 100
syntax is supported.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3907>
This adds a check which makes sure that the required GLSL/GLSL ES
versions are supported.
It also splits out the GLES version check into its own function, just
like GL does.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3907>
As it was originally the function to be used before
making it private and providing safer wrappers around it for x11/win32.
Nowadays, it is only used in x11 and only internally in mutter, exposing
a 'safer' variant costs us exposing more of x11 renderer APIs without
much benefits.
With this change, the only internal xlib renderer we need from meta is
set_foreign_display which can't be easily worked around
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3910>
