[GSoC] KWin colour management

[Kai-Uwe Behrmann]

Am 21.03.12, 20:34 +0100 schrieb Martin Gräßlin:
> I think you do not know how KWin's rendering works. In a simplistic way: a
> window is rendered to the screen through a shader. At runtime KWin decides
> which shader to be used. As by that there is always only one active shader, so
> to have color correction it has to be added to all shaders which render
> windows/textures/colors.

Thanks for the description.

> This is different to any experience you might have from Compiz 0.8. There the
> screen was not rendered with shaders but plugins could use shaders.

>>> Do you have any references showing that it is impossible to add color
>>> correction to Qt during the lifecycle of Qt 5? I'm sorry, but I don't base
>>> technical decisions on "my feeling says".
>>
>> That would mean colour management appears earliest inside Qt 6. But it is
>> at the moment not clear if that happens at all.
> Any proof for these bold statements? Anything from Qt where I can see that
> this is the case (also for Wayland)? Remember nobody wants to develop for X
> anymore ;-)

As we discuss a equivalent of colour management in KWin, we talk about 
default colour management of all displayed Qt widgets. That is a high goal
and likely coming with some API changes. Such changes need quite some 
preparation.
What signs are visible that with the first release of Qt 5 will have full 
CM? Even if people would put CM now high on the Qt develpers or similar 
agendas, CM will likely not get included soon to be ready for the first
Qt 5 release. Then logically the next feature window is Qt 6.

>>>> On the other hand, Xorg architect Jim Getty told me, that compositors
>>>> are the right places for colour correction.
>>>
>>> that might be quite true, but not if apps want to opt-out.
>>
>> The X Color Management spec allows for opt-out inside compositors.
>> I think to demonstrated you that on osC.
> and I think I explained to you why I don't think that's a good idea for KWin
> :-)

kind regards
Kai-Uwe