[GSoC] KWin colour management

[Martin Graesslin]

On Sunday 18 March 2012 20:01:01 Casian Andrei wrote:
> Hello,
taking it to the KWin mailinglist as that's the relevant list in case this 
proposal would be accepted.

First of all thanks for considering doing a GSoC project around KWin.
> I need your guidance in order to create a decent proposal. I
> understand the project will involve implementing the colour management
> features in KWin. As the idea suggests, this would imply making KWin
> handle the _ICC_COLOR_OUTPUTS and _ICC_COLOR_PROFILES atoms.
This would probably only be part of it.
> 
> Today I documented myself about colour management in general, and how
> it's done in Linux. I also read about ICC, Oyranos, X color management
> and related things. Now I'm not completely in the dark as before. I
> looked around in the KWin code and I found the area of interest - the
> compositor part, more specifically KWin::SceneOpenGL. Since shaders
> will be needed, it looks like some custom shaders of type
> KWin::ShaderManager::ColorShader would be able to do the job. Please
> correct me if this is wrong.
There is more into it: first of all KWin currently does not distinguish between 
screens during rendering. To properly have screen aware color correction the 
complete compositor has to be made screen aware. The repaint loop has to be 
split into multiple rendering passes - one for each screen. This is quite a 
change in the way how KWin renders, but might be a useful change.

As a second step all fragment shaders need to be adjusted to do the color 
correction. This has to be done extremely efficient. This is a rather critical 
code path especially for low-end hardware (think of old Intel GPUs). Given the 
constraints of the GPUs a dynamic feature activation is not possible.

What is in general important to know is that we have not had the best 
experience with GSoC students doing work on the core of KWin. Given that I 
proposed guidelines for future feature additions to KWin by non-core 
developers [1].

Furthermore I want to mention that the project would at max be co-mentored 
from the KWin team. The slot is provided by the Oyranos community and not by 
KDE. This means that the main mentor will be at Oyranos and also whether the 
GSoC completes or not will be judged only by Oyranos. A successfully completed 
project at Oyranos to write code to KWin does not mean that the code will be 
merged into KWin.

Given recent discussions on this mailinglist about Oyranos and colord I am 
very unsure whether I want any color management relevant code in KWin at the 
moment. I will definitely not accept any code supporting only one of the two 
systems and any additional build or run-time dependency to KWin will not be 
accepted.

In general there seems to be agreement that color management has to be done 
inside the toolkit/application and not inside the compositor. A fully color 
corrected compositor seems feasible to me, but one where some applications 
need to start opting-out of being color corrected is nothing I want to see in 
KWin as it adds significant complexity and overhead to the rendering process. 
This is something the Oyranos community has to decide on how they want to have 
that handled.

Kind Regards
Martin Gräßlin
KWin Maintainer

[1] http://community.kde.org/KWin/Mission_Statement