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>
This uses the luminance levels of the color states to anchor the white
of content instead of hard-coding the levels.
This also starts using uniforms for parts of the mapping which means we
don't have to generate and compile a shader when the luminance levels
change.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3953>
They represent the minimum and maximum luminance levels of the primary
color volume and the reference luminance level (reference white, SDR
white, ...) in the reference viewing environment.
They help anchoring the white level, optionally help with preserving the
dynamic range and help with adjusting from a "dark" to a "bright"
viewing environment.
The values have defaults which depend on the transfer characteristics.
This reflects the wayland color management protocol.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3953>
Actions might get detached sometime during event processing,
at a time that the stage did already prepare an emission chain
holding references to the actions and actors that need to handle
events. This means actions might become detached, but still handle
the incoming event, or possible crossing events generated in-place
when the actor becomes unparented.
Avoid this situation, by skipping event handling on actions that
went detached, we will just instruct to continue event processing.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3988>
Instead, get it from the context. See next commit
For ClutterText, we had to switch to using constructed
as the ClutterContext will be set for the ClutterActor in the
constructor phase
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3977>
See previous commit log on the effects of this.
This means the deadline evasion needs to be added in both cases in
clutter_frame_clock_notify_presented.
v2:
* Use meta_kms_update_set_sync_fd. (Jonas Ådahl)
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3958>
As a writable property, nothing sets it in both Mutter/GNOME Shell
making it a dead-code. As we will be moving pango related bits to
gnome-shell, remove this one already
Removes pango-ft2 dependency
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3969>
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>
