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>
The initial target color state is the color state of the stage view
being painted to. If we're painting to an arbitrary framebuffer, it's
currently hard coded to sRGB/electrical.
The content color state is not set on construction, but when starting to
paint, it's set to the color state of the stage itself. Whenever an
actor is painted, it'll set the color state to the color state of
itself. The intention is that offscreen rendering pushes a target color
state that causes painting to it to not necessarily be in the stage view
color state.
Pass color state with offscreen framebuffer, as this avoids hard coding
sRGB in the lower level bits of paint contexts. It's still practically
hard coded, only that it's derived from somewhere else (e.g. the stage
or window actor).
Nothing is actually using this yet, but will eventually.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3433>
This aims to provide the color state used for compositing for a specific
view. It's currently hard coded to default, but will eventually be
configured depending on the monitor and configuration. It's intended to
be used as a target color state for rendering with color awareness.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3433>
The cogl shader cache uses snippet pointers as cache keys, meaning even
if we generate two identical snippets; if they have different pointer
addresses, they'll generate separate cache entries. Handle this by
caching our snippets on the context.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3433>
This helper generates shader snippets that converts pixels from one
color state to another. For example if there is content with sRGB color
state that should be converted to linear BT.2020 before being written to
the framebuffer, a shader that makes the pixel go through the following
steps will be generated:
1. sRGB EOTF
2. Luminance gain (hard coded for now)
3. Color space mapping
The intention is that it should be possible to composite in a linear
color space, into an intermediate framebuffer, which is then passed
through an inverse EOTF to produce linear content in the output color
state.
When transforming from BT.2020/PQ to sRGB/sRGB, clamping to the sRGB
max luminance is done.
Cases where direct transform is also handled, i.e. where one doesn't go
via an linear intermediate buffer, in which case there might be both an
EOTF and an inverted EOTF in the same shader snippet to still do color
space mapping using optical color encoding. This will be used for e.g.
transforming cursor sprites.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3433>
An unknown color space isn't very useful to have, as there is not very
actionable what to do with it. Rename it to 'default'. Later it'll be
used to an implicit color space, which in practice will be treated as
sRGB.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3433>
The context can be set via a property (currently unused) or via the
current global singleton as a fallback. It means API that acts on an
actor can avoid going via any globals.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3433>
This gives greater control to the callers on the place where a grab is being
activated, this may make a difference in the handling of crossing events
triggered through it, e.g. by having callers rely on having already obtained
a ClutterGrab prior to handling the resulting effects.
The "input only" grab has also been turned inactive by default, in order to
to have the ClutterGrab pointer available for checks at the MetaWaylandEventHandler
focus changing methods triggered through grab activation.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3463
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3747>
Inside the "if (clutter_actor_has_accessible (actor))" condition,
the 'atk_child' variable is set and a signal is emitted on it.
There is a classic ref/unref dance around the signal to guarantee
that 'atk_child' won't be destroyed.
However, this ref/unref dance doesn't work, because the unref is
done *before* the 'atk_child' variable is used again. So if this
was the last reference to it, it would have been destroyed in the
unref call, then used for another signal emission a few lines down.
That's a use-after-free.
Fix that by declaring the 'atk_child' variable with g_autoptr. This
delays the unref until the very end of the function, and is NULL safe.
Also add a sneaky assertion, just for extra safety.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3828>
Currently AtkActor iface is implemented by CallyActor as well
as a ton of infrastructure just for one action in ClutterText, the
activate action.
Instead, simplify the whole thing and move the AtkAction implementation
where it supposed to be.
This refactoring would help with merging Cally within Clutter in
the future
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3814>
If the presentation time isn't known, e.g. if the monitor is virtual and
the actual presentation happens far away, the presentation time we
actually received tends to be the time a frame was presented to the next
layer, meaning practically immediately after painting.
When scheduling another update after that, don't assume that if the next
calculated update is not the immediate next update, schedule an update
sooner, as that will in such cases always be true, meaning we ended up
busy looping with constant frame updates being scheduled.
Fix this by only triggering that logic if the last presentation time was
actually vsync:ed.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3803>
