The constructor already copies the pipeline which means we can add a
snippet safely without affecting the parent pipeline, without creating
another copy.
Fixes: 6b07141f1a ("clutter/paint-nodes: Make paint nodes handle color transformations")
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4037>
As it ends up using the global default context. So just call that
directly to easily spot the remaining usages of get_default_context.
Note that the helper will probably be removed later this cycle once the
remaining usages in meta & libst have been replaced with passing around
the context
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4077>
As they are not used anywhere, in the next commit
we will just remove the whole thing and use glib helpers directly as
there is nothing specific about ClutterThread anymore
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4077>
While in double buffering we only care about one previous presentation,
triple buffering will sometimes need to refer to the presentation from
two dispatches prior. So it might help to separate those frame stats
more clearly. This way each frame's dispatch and presentation times are
stored more cohesively such as to not be overwritten during overlapping
frame lifetimes.
Having two types of frame reference (dispatch and presentation) moving
at difference speeds meant that they could not be stored in a ring. Not
all dispatches become presentations and so storing them in a ring would
necessitate very complex conflict avoidance. Instead, a simple reference
counting model was used.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3961>
So that we maintain a perfectly balanced number of callbacks:
dispatch == notify_ready + notify_presented
Otherwise you can't put any useful logic inside notify_ready and be sure
you're handling all the empty frames.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3961>
As that is where the whole text rendering integration happens
And would allow us to get rid of some over-abstraction in cogl-pango,
simplify
ClutterSnapshot integration as well
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4004>
Instead of duplicating a string we own already we can just steal it from
the array that we're using.
This is safe since we're sure about the tokens GStrv length and we are
always stealing the last element, so there is no risk that g_strfreev
would eventually leak something.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4071>
Previously ClutterStageWindow was an interface with only one base
implementation (MetaStageImpl) which others inherit from.
This just makes it a class so that we can use _GET_CLASS() API instead of
the costly (by comparison) _GET_IFACE() vtable lookups.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4048>
clutter_primaries_to_wayland made sense when there only existed
ClutterColorspace. Now that ClutterPrimaries also exist, it makes more
sense to change that func to clutter_colorspace_to_wayland.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4062>
Quoting Ebassi https://www.bassi.io/articles/2023/02/20/bindable-api-2023/:
Whenever you’re describing a function that takes a callback, you
should always annotate the callback argument with the argument that
contains the user data using the (closure argument) annotation
You should not annotate the data argument with a unary (closure).
The unary (closure) is meant to be used when annotating the callback
type
Recently gobject-introspection became a bit more strict with this and
that generated some warnings:
Warning: Cogl: invalid "closure" annotation: only valid on callback
parameters
This commit fix all the closure annotations.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4058>
This TF can't be defined as a TransferFunction enum because it needs a
gamma_exp value too.
Add to EOTFType enum a new type: EOTF_TYPE_GAMMA.
With this new type, now EOTFs are unions that can have either
a TransferFunction enum or a gamma_exp.
Set gamma_exp as uniform.
Add the support of it in the color management protocol.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4020>
These properties now are tagged unions:
- ClutterColorimetry:
Can be from colorspace or primaries;
- ClutterEOTF:
Can be from known tf or custom gamma exp (next commit);
- ClutterLuminance:
Can be defined explicitly or derived;
Make the color management protocol use them too.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4020>
ColorState is inmutable so the GObject properties aren't necessary.
Also move ClutterColorstate and ClutterTransferFunction enums to
color-state.h now that they are not used as GObject properties.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4020>
For non-debug and non-plain cases - i.e. mainly release builds.
This ensures we use the same options in all places and draws a cleaner
distinction between g_assert() and g_return_if_fail() - the later will
still be done in release build while the former are meant for debug
only.
One advantage of doing this is that it allows us to use non-trivial
asserts more generously, such as calling `g_list_length()`.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3424>
Colorspace transformation matrices were hardcoded considering only known
colorspaces like bt709 or bt2020.
Now that a colorspace can be defined from its primaries, allow getting the
colorspace transformation matrix from them and drop the hardcoding.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3948>
This is because next commits will generate the colorspace
mapping matrix from the colorspace primaries and won't be required
to define any color space mapping matrix.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3948>
We only need to wake up the other side of the GAsyncQueue if we transition
from 0 to 1 item in the queue. Otherwise, we can be certain that the other
side has received a wakeup and will eventually flush the queue.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4007>
