[GSoC] KWin colour management

[Martin Gräßlin]

On Wednesday 21 March 2012 19:14:51 Kai-Uwe Behrmann wrote:
> Am 21.03.12, 18:20 +0100 schrieb Martin Gräßlin:
> > On Wednesday 21 March 2012 08:23:39 Kai-Uwe Behrmann wrote:
> >>> 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
> >> 
> >> As a side note, during the last CLT fair there was the idea brought up,
> >> to
> >> place ICC colour correction inside a KWin plugin. Is that recommendable?
> > 
> > I'm kind of confused by this question: I just wrote that the compositor is
> > not screen aware. How should a plugin be able to handle screen aware
> > rendering if the core does not?
> 
> I can only speak from the existing colour server plugin. It does handle
> per screen colour correction regardless of support in the actual used
> compositor. Of course it needs a n-screen loop for drawing all screen
> overlapping windows.
I assume you speek of the plugin for Compiz. Please note that KWin has a 
different rendering architecture which needs to be adjusted. It is pretty much 
irrelevant how it works on Compiz for the usage inside KWin. As I have written 
now multiple times: KWin does not support rendering per screen.
> 
> >>> 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
> >> 
> >> Which shaders and adjusted for what specifically? May you point us to
> >> them, in order to get an idea?
> >> http://quickgit.kde.org/index.php?p=kde-workspace.git&a=tree&f=kwin
> > 
> > As KWin renders through shaders and I expect that the screen should always
> > be color corrected the answer is simple: all of them.
> 
> A 3D texture lookup is done usually only once inside the pipeline. The
> plugins inside the kwin/effects path might be used simultaneously.
> So placing a additional 3D texture lookup into each of those plugins would
> lead to unwanted multiple colour corrections.
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.

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.
> 
> >>> 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.
> >> 
> >> The more we are interested to see the KWin project being involved.
> > 
> > Whether a project succeeds or not does not depend on KWin being involved
> > in
> > this project. It's the mentor and student who have to ensure to develop
> > code acceptable to the requirements of KWin development.
> 
> Personally I would not make inclusion of code a pre condition for the
> success of such a project. Upstream inclusion of code is a high goal for
> contributors anywhere. Not many GSoC projects reach that immediately.
If you don't aim for inclusion into KWin, I seriously do not see why such a 
project is needed. Given the changes inside KWin I doubt any of the code could 
be reused let's say a year later.
> > 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 ;-)
> 
> >> 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 
:-)
> 
> >>> 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.
> >> 
> >> Opting out of colour management is a pre condition to do
> >> * raw measurements, such as for ICC profile generation
> >> * application side specialised colour correction
> >> 
> >> It needs to internally store the colour transform per window. If there is
> >> none, then there is no conversion needed.
> > 
> > in other words: it affects all windows and adds significant rendering
> > overhead to it as it has to be decided whether there has to be a
> > conversion or not. That's exactly what I wrote and why I don't want the
> > complexity inside KWin.
> What would KWin people suggest how and where to place this feature near
> KWin?
> (CM in Qt is unfortunedly not a secured and short term [one year] option.)
Well the question is whether such a feature is needed at all. I would say:
* either correct the whole screen
* or let the windows handle it

Now it becomes quite simple: there's an app doing color correction itself. In 
that case we can safely assume that the user wants the app to take care - 
compositor does no longer color correct the screen.

There is no application taking care of it: compositor renders the whole 
screen.

Cheers
Martin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20120321/45c7dd77/attachment.sig>