Niels Ole Salscheider wrote:
The color correction protocol allows to attach an ICC profile to a
surface. It also tells the client about the blending color space and
the color spaces of all outputs.
As you pointed out, it does look like this has to be done by the
compositor, because a different color correction has to be applied to a
surface for each output. Since a surface can appear on more than one
output simultaneously, and that information is not available to a
client, the compositor must do this.
+ <request name="set_profile">
+ <description summary="set the color profile of a wl_surface">
+ With this request, the color profile of a wl_surface can be set.
+ When mode is set to "profile", an ICC profile can be passed in the
+ "profile_data" argument. In all other cases, "profile_data" is
+ ignored.
+ "mode" should only be set to "uncorrected" for fullscreen applications
+ or applications that really require uncorrected output (e. g. color
+ profiling tools).
+ </description>
+ <arg name="surface" type="object" interface="wl_surface"/>
+ <arg name="mode" type="uint" />
+ <arg name="profile_data" type="array"/>
+ </request>
This should be double-buffered: it does not happen until a commit.
I would make the profile be an object, not a block of data, so it can be
reused easily. (this is in addition to the other discussion of how the
data is conveyed between client and compositor). The "mode" can be
eliminated by making special profile objects for each mode.
+ <event name="blending_space">
+ <description summary="tell the client what blending space is used">
+ This event will be sent when the blending space of the compositor
+ is changed. A client can use this information to output its surface
+ in the blending space of the compositor so that only one color
+ transform (from blending to output space) has to be performed by the
+ compositor. This can result in better performance.
+ </description>
+ <arg name="profile_data" type="array"/>
+ </event>
I don't like this description. There may be a "linear" blending space,
but the purpose is not to describe some "faster" space. In fact sending
the buffer as a linear color space may be much slower and look much worse.
A compositor does not have to implement a linear blend by converting the
source to linear space and building a buffer of linear values. Instead
it can do it with amazingly crude approximations. For instance replacing
a+b with sqrt(a^2+b^2) will do a pretty good job of adding two sRGB
images together, indistinguishable by eye from the accurate result. And
the source and destination are all in sRGB space.
The reason clients want to know the blending space is because it changes
how partially-transparent areas, in particular shadows, are stored in
the source, especially if the client wants to draw internal shadows in
the buffer that "match", or set the drag&drop cursor to am image that
actually composites correctly into the drop target.
I suspect also the blending space may vary depending on the surface: it
may do a subsurface different than a parent (especially for remote
display), and if overlay planes are used it may change the blending
space. Maybe it would be sufficient to send this per-surface.
_______________________________________________
wayland-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
