[compiz] color management spec

[Kai-Uwe Behrmann]

Am 10.06.08, 17:56 -0400 schrieb Owen Taylor:
> On Tue, 2008-06-10 at 16:43 +0200, Tomas Carnecky wrote:
> > Added gtk-devel-list at gnome.org to hear their opinion about this matter. 
> > For reference, this is what I proposed:
> > http://lists.freedesktop.org/archives/xorg/2008-May/035772.html
> > 
> > Danny Baumann wrote:
> > > Hi,
> > >  
> > >>> I strongly dislike supporting subwindow ID/profile tuples. 
> > >> The task of 
> > >>> window and compositing managers is and always has been to 
> > >> manage and 
> > >>> draw _toplevel_ windows, not subwindows. I don't really think that 
> > >>> adding a subwindow management infrastructure to compositing 
> > >> managers 
> > >>> just for saving some lines of code in the toolkit (and not 
> > >> even all of 
> > >>> them) is an overly good idea.
> > >> It's not just for 'saving some lines of code in the toolkit'. 
> > >> Color management would require significantly more code in the 
> > >> toolkit and would most likely be slower then if it is done in 
> > >> the compositing manager.
> > > 
> > > I was just talking about "communicate using subwindow id/profile tuples" vs.
> > > "communicate using toplevel window region/profile tuples". The former would
> > > save a bit of code in the toolkit, but would complicate compositing managers
> > > significantly; which is why I strongly prefer the latter.
> > 
> > The compositing manager would never actually draw subwindows, just 
> > merely use them to identify regions.
> > 
> > When using properties on the top level window, the toolkit would have to 
> > explicitly update those whenever the window is resized. But when using 
> > subwindows, the toolkit (at least gtk) wouldn't have to do anything 
> > special. In gtk, each widget that uses a subwindow resizes it when the 
> > top level window is resized. The compositing manager would just 
> > subscribe to ConfigureNotify events of the subwindows and be done.
> 
> If I was working on a new toolkit from scratch it would most likely have
> no subwindows, or a very, very limited use of subwindows.
> 
> In the case where you do have subwindows, future toolkits will commonly
> act as compositing managers for their own subwindows, so a subwindow
> does not necessarily represent an integer-pixel-bordered region of the
> window.
> 
> I have trouble seeing the idea of separate profiles for subwindows
> as being a good idea. There are also other problems like:
> 
>  - There's no easy way to get or be notified of changes to the 
>    clip region of a window in X. If a subwindow with a separate
>    profile was partially obscured by another subwindow, the compositing
>    manager would have trouble tracking that.
> 
>  - If there was inter-process embedding, the ID's of subwindows with
>    separate profiles would have to be propagated up to the toplevel,
>    which would be a pain. (You don't seem to have a
>    WM_COLORMAP_WINDOWS equivalent, but one would be needed.)

Are colour maps applicable in the range of this project? I'd guess that 
OpenGL cards with the necessary features for compiz would run almost 
always in a true visual mode?
 
> The _NET_COLOR_MANAGER client message also introduces a whole lot of 
> complexity for toolkit authors.
> 
> I assume that the problem you are trying to solve here is:
> 
>  A) Photo app has a embedded image in a wider-than-SRGB-colorspace
>     plus some random toolbars
>  B) You don't to convert the image to SRGB and lose gamut that the
>     monitor might actually be able to reproduce

  C) Deploy a fast colour conversion path on the GPU rather than the CPU

  E) Manage the whole desktop at once, like it is displayed at once.

> While the suggestion of subwindow tracking is seductive, I don't think
> it really works out. So, you need to go with one of the other
> possibilities - either you export the monitor profile to applications
> and allow applications to mark windows as being in the monitor profile,
> or you put the whole window into the image colorspace. (Using the
> monitor colorspace obviously works better if there are multiple images
> with significantly different gamuts in the same toplevel.)

Tagging the window with the image colour space will render in rather a 
mosaic of windows.
The other suggestion is covered by the _ICC_PROFILE_xxx atom but misses a 
practical use case.

> Either way, this end up with the question ... how do you get a
> toolkit dealing with some non-SRGB colorspace? I don't have a full or

sRGB:
http://www.w3.org/Graphics/Color/sRGB.html
is a special, close to a idealised monitor, colour space. We have nearly 
nowhere such devices. Toolkits typical display on real world devices 
which differ from sRGB.
The sRGB would have to be supported by the drivers, which would introduce 
a rather big burden on them. One partitial answere are video LUT's, which 
are limited to neutrality management with several drawbacks. 
With any computational intensive approach, a system to indicate damage or 
request rerendering is a nice work load saver (XDamage?).
The project of Tomas moves the necessary driver implementation to a higher 
layer and deploys hardware (GPU) in a more generic way. So it seems 
overall reasonable.

What would interesst me, how is XDamage different from the 
_NET_COLOR_MANAGER message? Is there possibly something overlapping?

> even partial answer to that, though there are obvious ways you could
> start extending RENDER and cairo to work toward that goal. For the

We discussed this at LGM to start there too.

> photo app, most professionals probably wouldn't be that upset if the
> menus and toolbars got the wrong colors as long as their photos got
> the right colors...

That case was a complaint from users and one of the reasons to start 
projects like Tomas did.


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