GSoC CM collaboration

[Tomas Carnecky]

Olivier Galibert wrote:
> On Mon, Mar 03, 2008 at 08:29:24PM +0100, Tomas Carnecky wrote:
> You're making my point here.  You want the newer gtk engines to
> integrate the color conversion in their opengl pipeline.  And anyway
> you want to render the UI using colors/color ramps you've already done
> the lookup on.  That's the point of doing it in the toolkit, you have
> a higher-level point of view allowing to collapse operations.

My bad, the gtk engines I had in mind (clearlooks, murrine) use cairo, 
which uses xrender as its backend and not glitz (OpenGL). Apparently 
glitz is much slower then xrender. So no OpenGL there.

IIRC one email in this thread mentioned that the window contents should 
be left untouched, in case the application wants to read the pixels back 
and do something with them. When using xcomposite you basically get that 
for free. The compositing manager does not touch the original window 
contents, it only reads from it and renders it into the frontbuffer, 
applying whatever transformations the user wants.

You want to do the color conversion on the toolkit level, so unless you 
disagree with the above requirement, it will quickly get much more 
complicated for the toolkit. You would have to keep two copies of each 
pixmap/drawable: in one the original data and in the other the converted 
pixels. Given that Firefox for example creates loads of pixmaps, the 
memory consumption would grow significantly. Much more then in the 
presence of a compositing manager. So I don't think the toolkits will 
implement this anytime soon.

>> Part of the GSoC project I could do some performance measurement to see 
>> how much faster the conversion on CPU vs. shaders is, how big the 
>> difference is on a normal desktop etc.
> 
> That wouldn't tell you how much faster it is to do it at a higher
> level.

I could simulate the color conversion at the higher level as well. But I 
doubt the performance is an issue here, chips will only get faster, and 
nowadays they have more then enough power to do what we want.

>> So applications that _do_ care about colors already manage them, so 
>> really, where's the problem?
>> ... it was my impression that Kai-Uwe wanted to have this color 
>> management integrated X, in a way so that all applications could profit 
>> from it. So I'm proposing a solution that is as far down on the stack as 
>> possible, in a place where all applications would automatically profit 
>> from it, no matter which toolkit they are using.
> 
> But if it isn't painless, since it's only for "unimportant"
> applications, it will just be turned off.  Me, I'd like something I
> can leave on without caring.  Do you want your work to be used only by
> a micro-minority?

Why do you think it would be painful?

Or rather, what exactly do you want? It's not about the professional 
applications, because these work nowadays. From what I understand you 
want to add ICC profile support to as many applications as possible, 
right? Well, I'm with you so far. I also see that putting the color 
conversion code into toolkits has its advantages, but in the long run I 
think that letting the compositing manager do it makes more sense. In 
any case, a resulting specification and implementation of it should 
allow the application so completely bypass any color conversion, so that 
toolkits and applications can do that on their own.


It would be interesting to know how Windows/MacOS handles these issues. 
Is it handled transparently for all applications? Or does each 
application have to explicitly ask the OS do convert its colors to the 
monitor colorspace? Or do these operating systems provide functions for 
the transformation and each app has to do that manually before it 
renders the pixels into its window? Can multiple windows be in different 
colorspaces and still be rendered correctly on the monitor?

tom