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 t=
his=20
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 managemen=
t
> 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.
>=20
> Today I documented myself about colour management in general, and how=

> it's done in Linux. I also read about ICC, Oyranos, X color managemen=
t
> 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=20
screens during rendering. To properly have screen aware color correctio=
n the=20
complete compositor has to be made screen aware. The repaint loop has t=
o be=20
split into multiple rendering passes - one for each screen. This is qui=
te a=20
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 col=
or=20
correction. This has to be done extremely efficient. This is a rather c=
ritical=20
code path especially for low-end hardware (think of old Intel GPUs). Gi=
ven the=20
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=20=

experience with GSoC students doing work on the core of KWin. Given tha=
t I=20
proposed guidelines for future feature additions to KWin by non-core=20=

developers [1].

Furthermore I want to mention that the project would at max be co-mento=
red=20
from the KWin team. The slot is provided by the Oyranos community and n=
ot by=20
KDE. This means that the main mentor will be at Oyranos and also whethe=
r the=20
GSoC completes or not will be judged only by Oyranos. A successfully co=
mpleted=20
project at Oyranos to write code to KWin does not mean that the code wi=
ll be=20
merged into KWin.

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

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

Kind Regards
Martin Gr=C3=A4=C3=9Flin
KWin Maintainer

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