Re: [compiz] color management spec

[Tomas Carnecky <tom dbservice com>]

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.

tom