[Openicc] Color Management for Ubuntu

Richard Hughes hughsient at gmail.com
Thu May 5 02:11:44 PDT 2011

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
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.

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
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.

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.

So in this way, libxcm to me seems very tied to the way compiz works,
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
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.

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.


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

More information about the openicc mailing list