[Openicc] Color Management for compositor mutter
hughsient at gmail.com
Thu May 5 04:16:46 PDT 2011
On 5 May 2011 10:55, Kai-Uwe Behrmann <ku.b at gmx.de> wrote:
> "Actor" like in theather(?). That would be a window region?
An actor is just an animatable blob. I'm pretty sure there are a few
actors for each window, although I'm not sure of all the details.
> Texture scaling is a intermediate step. What is interessting is the end
> state of the windows. If the colour conversion is applied there the
> net-color spec works pretty naturally.
Of course, except that's not really how clutter works.
> But that appears to be a general problem of
> compositing at this time in Xorg space.
Yup, and that's why I failed to get anything like
gtk_widget_set_color_opt_out() working -- the widget had no concept of
the final window transformation and so couldn't send updated
coordinates even if it wanted to. That's why I'm kinda confused that
the net-color-spec talks about XserverRegions.
> KWin developers have problems either with adoption. But they dont general
> bash the spec. They concentrate on solving problems in their implementation.
I'm not bashing the specification.
> What shall gnome-color-manage do for the net-color spec?
Interface with the window manager, although, I suppose mutter could
talk to colord directly for the window profiles as each colord device
has metadata about what xrandr output it's assigned to.
Backtracking a few hundred steps: Trying to convince an application
author to add a few low-level libxcm specific calls in an existing
graphics or profiling application might be a hard sell, and impossible
for a lot of proprietary software used already by the studios. It
would also break a lot of expensive software if we rolled out WM CM in
Linux without _every single existing application_ being ready for it.
Wouldn't it be better to allow new applications to opt-in certain
More information about the openicc