GSoC CM collaboration
tom at dbservice.com
Mon Mar 3 18:41:41 PST 2008
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
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?
More information about the xorg