[GSoC] KWin colour management

[Kai-Uwe Behrmann]

Am 22.03.12, 07:34 +0100 schrieb Martin Gräßlin:
> On Thursday 22 March 2012 07:02:27 Kai-Uwe Behrmann wrote:
>> Am 21.03.12, 20:34 +0100 schrieb Martin Gräßlin:
>>>>> 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.
> Sorry but I don't follow that logic. Just because it won't make it into 5.0
> (which is impossible) does not mean that it won't enter any 5.x release.
>
> And that's what I asked for: is there any reference stating that it won't be
> possible to add CM to Qt in the lifetime of Qt 5?

Here my thoughts, why I think CM in Qt is not easily introduced during a
minor Qt 5 release. [Preparation of CM for Qt 6 is a different story.]

Lets hypothetical assume some effort is initiated to bring CM to Qt and 
that happens during Qt 5 life time. The new design says by default all 
content is considered sRGB, which is by itself reasonable. However 
existing applications will initially not know about that changed 
convention. There is currently no API to know that. They will play 
freestyle as before and colour correct to monitor space without knowing 
how to tell anything to Qt. These old style apps will colour correct to 
monitor and Qt will colour correct from sRGB to monitor as Qt does not 
better know. That is called double colour correction and would be a real 
design bug.

The conflict is solveable by making the new drawing API incompatible with 
the old one, e.g. requiring a colour space argument. An other way is 
verbally declaring sRGB as the default colour space in Qt, which would be 
a major API change as well and only reasonable possible during major 
version change.

Both is not easy before Qt 5. After the fist Qt 5 release a new drawing 
API could theoretically be introduced in parallel to the old one. But old 
Qt apps would then look inconsistent compared to ones using the new API. 
Not sure if that transition path would be a good option regarding code 
complexity. IMO best would be to wait for Qt 6 and then switch completely.

kind regards
Kai-Uwe Behrmann
-- 
www.oyranos.org