GSoC CM collaboration

[Kai-Uwe Behrmann]

Am 03.03.08, 18:47 +0100 schrieb Olivier Galibert:
> On Mon, Mar 03, 2008 at 06:28:48PM +0100, Kai-Uwe Behrmann wrote:
 
> > 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.

Ok I understand. You speak about efficiency. Tuning can happen in various 
places. 

But I feel we should start with a clear concept. 

Once that runs, people, including toolkit developers, have something to 
refere to. Optimisations in advance have the disadvantage, that it's
often difficult to estimate if they succeed.

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

Yes, thats not so nice. But like with every architecture. There is a start 
needed. As long as this initial colour managed desktop works almost as 
proposed, despite the speed break down on some systems, there is something 
to easily continue.

A desktop with various hooks in various toolkits, for the favour of some 
unshure optimisation, will be terrible to manage later on. Thats my 
expectation.

As a workaround, CM could be switched of for slow laptops as you already 
mentioned for other gadgets.
 
kind regards
Kai-Uwe Behrmann
-- 
developing for colour management 
www.behrmann.name + www.oyranos.org