GSoC CM collaboration

[Olivier Galibert]

On Mon, Mar 03, 2008 at 06:28:48PM +0100, Kai-Uwe Behrmann wrote:
> Am 03.03.08, 18:01 +0100 schrieb Olivier Galibert:
> > On Mon, Mar 03, 2008 at 05:49:20PM +0100, Kai-Uwe Behrmann wrote:
> > > IMO it boils down, whether it makes sense to keep the CMS impact on the 
> > > application side minimal, or accept that a application has to call a CMS 
> > > in order to do any colour management.
> > 
> > Where "the application" can mean in large part "the graphics toolkit",
> 
> This is a simplification. The application is the place where a developer 
> decides, which toolkit widgets to show the user. The toolkit is not able 
> to do so.

The developer decides what.  The toolkit tends to decide how.  And
nowadays with app-side anti-aliasing that often means generating and
blitting a pixmap.  So what X sees is mostly only pre-rendered pixels.


> > as in gtk, qt or even cairo.  So it's not necessarily that numerous.
>  
> This is a call to soften a concept. We talk here about where to create the 
> colour transformation.
> I am not against placing this code in the toolkit in the first place. But 
> it seems more appealing to have the stuff in one place. This would be 
> where colour conversion happens - in the last pice of the colour chain.
> My take is toolkits should be CM aware and let it passing through.

Except for the cost.  How many people just switch off composite
managers because the cpu/gpu/power cost is high and what it gives in
exchange is some eye candy not worth it.  Especially when video comes
into the picture.  CM for normal users is almost on the same plane,
eye candy.  So it shouldn't carry a visible cost.

Running a pixel shader on everything you send to the screen is far
from zero cost.  Especially on laptops, which don't always have pixel
shaders in the first place.

OTOH, cloned windows are going to be a problem for doing it app-side.
Annoying.  Cloned windows are going to be a problem no matter what in
practice if you have only one fb instance.

  OG.