GSoC CM collaboration
ku.b at gmx.de
Mon Mar 3 10:08:45 PST 2008
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
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
As a workaround, CM could be switched of for slow laptops as you already
mentioned for other gadgets.
developing for colour management
www.behrmann.name + www.oyranos.org
More information about the xorg