Instead of doing that in both MetaStage & CallyStage.
This allows ClutterStage to also emits the relavant acessibility
bits directly without having a roundtrip through Cally
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3917>
material is almost no longer used in the code base and the
few remaining references makes it confusing when looking at parts
of the codebase. So rename the rest as well.
Note that this renames a DeformEffect property and the only extension
making use of it doesn't use the property so i think it is okay to do
so without deprecating the old property for a few releases
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3910>
The ID is required for the wayland protocol. In the future we might want
to spend a bit more effort to re-use existing color states when a new
one is requested and also try to re-use IDs instead of just counting up.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3897>
This means the pipeline can be manipulated after retrieving. This also
fixes a leak when adding pipelines to the cache, as we the pipeline
would take a ref, but when adding, we wouldn't clean up our own ref.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3897>
According to gmacros.h, G_STATIC_ASSERT is undefined for __GI_SCANNER__
because it causes confusion. Which is understandable, and so is the
complaint about the lingering G_STATIC_ASSERT after preprocessing.
This problem seems to be unique to just clutter-deform-effect.h because
it's the only header file containing a top-level G_STATIC_ASSERT. The
rest are all in C files.
Fixes: 138e5d4f54
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3591
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3898>
The pointer returned by cogl_color_copy() was not stored anywhere and
the allocation it was pointing to got leaked. However we also don't need
to use that function here and can just copy the struct values directly.
Fixes: dc52ccc75 ("cleanup: Port from ClutterColor to CoglColor")
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3884>
A ClutterPipelineNode took a reference to the passed pipeline and used
it during the lifetime of the paint node. In theory this meant that a
paint node pipeline could be changed, and reused, affecting the previous
paint node drawing.
Referencing instead of copying also meant the ClutterPipelineNode isn't
able to itself manipulate the pipeline any further.
Fix both of these issues by copying, instead of adding a reference to,
the passed pipeline. While resulting in some additional allocation
over head, it means we can now eventually handle color transformations
automatically for ClutterPipelineNode's.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3433>
So far 'color-state' is added, intended to tag pipelines with color
state transformation capabilities. Color state transformation snippets
are tagged with it. Eventually handlers of pipelines will use this
information to on-demand decorate pipelines with color transformation
snippets.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3433>
Color aware rendering needs shaders / pipelines that adapt to what
output they render to. For example if we want to render to a linear
BT.2020 intermediate framebuffer on one monitor, and a non-linear sRGB
direct target buffer on another, the shader for the same paint node or
content will depend on where they are going to be presented.
In order to help keeping track of what shader should target what
monitor, without having to regenerate them each time, introduce a
pipeline cache that knows how to handle differentiating between
transforming between different color state.
The cache is meant to handle caches for multiple pipeline users, where
each user might potentially want to keep track of multiple pipelines
itself. Lookup should be O(1), and in order to achieve this, separate
the cache into 3 levels.
The first level is the "pipeline group", where e.g. a ClutterContent
type allocates a group where it can store its pipelines. Each group has
a fixed number of "slots" where it can store a pipeline. Each slot has a
hash table where the key is derived from a color state transform, and
where the value is a CoglPipeline where the thame color state
transformation is expected to be handled.
A content will when painting know about its own color state, and the
target state it should render into, retrieve a cached pipeline for the
correct transform, or if the cache didn't have it, generate it.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3433>
Allow compositing in a linear color space and do so either when forcing
it via the debug controls D-Bus API, or when the experimental HDR mode
is enabled.
This relies on paint nodes etc to actually transform everything into the
linear target color space, which isn't done yet, so enabling it right
now will cause a broken result. Yet, introduce this now, so that
painting can be fixed piece by piece.
Linear blending is automatically enabled on monitors where HDR is
enabled, as this makes it possible to use an linear color space when
blending content from different color spaces with different transfer
functions.
Linear blending requires extra precision, i.e. 16 bit per channel
in the intermediate buffer due how the values are distributed,
so only enable the experimental HDR mode if the Cogl context supports
half float formats.
By default, no intermadiate linear offscreen framebuffer is used.
To test, do e.g.
./tools/debug-control.py --toggle ForceLinearBlending
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3433>
