[RFC wayland-protocols v2 1/1] Add the color-management protocol

[Kai-Uwe]

Hello Sebastian and Pekka,

Am 04.03.19 um 15:44 schrieb Sebastian Wick:

> On 2019-03-04 14:45, Pekka Paalanen wrote:
...
> Not requiring a color space transformation at all (in the best case)
> by supplying a surface with the color space of the output.
>
>> Especially if device link profiles are taken out, which removes the
>> possibility of the application to provide its own color transformation.
With a
* device link profile or with
* color transform inside the application and attaching the output
profile to the surface,
in both cases the application provides it's own color transform. The
difference is, that in the former case to transform runs usually pretty
slowly on the CPU and memory optimisation for the whole system is not
possible. Each application is cooking on its own. In the later case the
conversion is performed by the compositor on the GPU, which is way
faster and the it can be easier optimised both in terms of performance
and memory wise.
> If the application has a device link profile it can just do the color
> space conversion on its own and assign an ICC profile of the resulting
> color space to the surface.

See above. Without offloading the conversion to the compositor, that
will be typical slower. Maybe I am wrong? But I do not see too many
applications doing GPU color management by their own. For certain they
do not share the color transforms in memory.

As a implementation detail, the compositor needs to cache the color
transforms in memory as they are expensive on first run or cache even on
disk. The later happens typical as device link profile. So, the
compositor might choose to support device links anyway. In my experience
on desktop color management and application color management, the
implementation effort for device link versus without is similar.

thanks,
Kai-Uwe Behrmann