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
