[Openicc] Color Management for compositor mutter

[Kai-Uwe Behrmann]

Am 05.05.11, 10:11 +0100 schrieb Richard Hughes:
> On 4 May 2011 22:41, Kai-Uwe Behrmann <ku.b at gmx.de> wrote:
>> So it appears more difficult to get desktop colour correction inside Gnome
>> 3.
>
> Yes, see below.
>
>> So you have already plans. Let me know if you have questions or need
>> details. I would be glad to help for Gnome.
>
> The basic problem is that mutter manages each window as a clutter
> actor. It then generates mipmaps of each window texture, so the window

"Actor" like in theather(?). That would be a window region?

> can be freely scaled and animated without any lag. The mipmaps are
> stored in a texture (as a 3d tower), as indeed the color transform
> data would be. The window drop-shadow effect is also implemented as a
> GLSL code snippet. I spent quite a bit of time trying to work out how
> to do both the mipmapping and the color conversion working along side
> the drop shadow and mipmapping, but ran out of time and patience.

Texture scaling is a intermediate step. What is interessting is the end 
state of the windows. If the colour conversion is applied there the 
net-color spec works pretty naturally.

> I can push my WIP mutter branch to gnome/github if you want, but it's
> basically the GLSL demo program[1] squashed into mutter in the right
> place. The biggest problem from an architectural point of view is that
> the mutter canvas isn't just a huge x-y window like compiz where you
> can assign a boxed area of the window and display to be a 'section',
> it's a dynamic window manager where physical screen co-ordinates are
> not so relevant as everything is being managed in a clutter scene. I'm

The colour management in CompICC happens on a per window level. Not sure 
what leads you to the conclusion to see "a huge x-y window".
Compiz has a fine grained control to many levels of the compositing 
process.

> sure there are some pretty obvious problems declaring a fixed
> opt-out-region when the windows themselves are often shown in the
> gnome3 overview, scaled and in different positions.

The windows can only tell in those coordinates, in which they are expected 
to draw on the screen. This is the normal resolution of the window 
coordinate system. How the compositing manager applies any matrix or other 
transformations must clearly be communicated back. Otherwise windows are 
kept in the dark which is a architectural flaw on the geometric 
transformation level. But that appears to be a general problem of 
compositing at this time in Xorg space.

> There's also the fact that even for a generic "window" that's opting
> out of the GLSL color conversion, we probably want to still color
> manage the window controls and the embedded widgets like the window
> border and the resize gripper. This kinda implies client side windows,
> which adds another world of pain.

OpenGL has means to apply operations to texture regions. The underlying 
subwindow logic should play not much a role for OpenGL.

> So in this way, libxcm to me seems very tied to the way compiz works,

Not at all. It communicates window coordinates just like Xorg. The same 
coordinates are used for the XDamage extension and many Xorg related 
communication.

> which makes it somewhat unsuitable to how things would be done in
> mutter. This is one of the reasons I experimented integrating the
> opt-out logic into the toolkit so a lot of the problems get taken care
> of automatically, at a cost of increased integration with the

How would Qt, TK and other toolkits be able to opt-out? There needs to be 
some common layer of communication. Otherwise its pretty unrelyable.

> platform. I certainly don't think "blessing" libxcm makes a lot of
> sense if it doesn't seem to work well with the window manager
> architecture used in GNOME 3.

KWin developers have problems either with adoption. But they dont 
general bash the spec. They concentrate on solving problems in their 
implementation.

> That said, I think doing the display color transform on the GPU makes
> a lot of sense for some people, and that I should probably support
> that operation mode in gnome-color-manager.

What shall gnome-color-manage do for the net-color spec?

> Richard.
>
> [1] http://git.gnome.org/browse/gnome-color-manager/tree/tools/gcm-glsl-demo.c

regards
Kai-Uwe Behrmann
-- 
developing for colour management 
www.behrmann.name + www.oyranos.org