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>
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>
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>
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>
Group all the three config files from clutter/cogl/meta into one
and also remove unnused configurations and replace duplicated ones
This also fixes Cogl usage of HAS_X11/HAS_XLIB to match the expected
build options
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3368>
ClutterColorState, that is a GObject. each ClutterActor would own
such an object, and it'd be set via a GObject property.
It would have an API to get the colorspace, whether the actor
content is in pq or not, and things like that.
if it is NULL, it will default to color state with sRGB colorspace.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2443>
