Re: [compiz] color management spec

[Owen Taylor <otaylor redhat com>]

[ Intentionally not trimming quoting much due to various bounces from lists ]

On Wed, 2008-06-11 at 09:05 +0200, Kai-Uwe Behrmann wrote:
> 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 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?

WM_COLORMAP_WINDOWS is just an analogy; in the same way that
WM_COLORMAP_WINDOWS identifies subwindows that have different colormap,
you would need a property to identify subwindows with different color
profiles. *If* you wanted to put color profiles on subwindows (something
that I think is a bad idea.) The expense for the compositing manager to
monitor all subwindows of each toplevel for property changes would be
extreme.

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

I don't understand this.

> The other suggestion is covered by the _ICC_PROFILE_xxx atom but misses a 
> practical use case.

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

Trying to calibrate the video card via LUTs to be as close as possible
to sRGB is certainly not an ideal solution. But on other hand, the
default handling for a toplevel window should be that the colors in that
toplevel window are in sRGB space. And the compositing manager can
do the conversion. I think that architecture makes a lot of sense.

And if you want to use more of the monitor gamut than is available via
sRGB, then you can tag have windows that use different colorspaces
(possibly including the raw monitor colorspace.) Also makes sense to me.

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

I think the overall project is reasonable. Being able to specify
per-window color profiles; have them properly converted as you move the
window between monitors, etc, would be a big advance. I'm just skeptical
of the idea that that the compositing manager should treat different
regions of a single toplevel differently. 

There's certainly no reason we can't use the GPU for colorspace handling
within a window as well. 

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

I don't quite see the connection. Compositing managers already track
damage via the XDamage extension. The _NET_COLOR_MANAGER message as I
understood it was about figuring out whether the compositing manager
supported particular colorspaces (I would have just used a root or
selection window property...)

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

Only having the toolbars in the particular toplevel window be messed up
would already be a big advance compared to the current system where you
have to configure things globally.

- Owen