On Tue, 2008-06-10 at 16:43 +0200, Tomas Carnecky wrote:
> Added [EMAIL PROTECTED] 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.)
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
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.)
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
even partial answer to that, though there are obvious ways you could
start extending RENDER and cairo to work toward that goal. For the
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...
- Owen
_______________________________________________
compiz mailing list
compiz@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/compiz
