Am 20.12.2016 um 15:25 schrieb Daniel Stone: > On 19 November 2016 at 16:29, Niels Ole Salscheider > <[email protected]> wrote: >> + <request name="colorspace_from_fd"> >> + <description summary="creates a color space from an ICC profile"> >> + This request allows to create a zwp_colorspace_v1 object from an ICC >> + profile. The fd argument is the file descriptor to the ICC profile >> (ICC >> + V2 or V4). >> + </description> >> + <arg name="fd" type="fd" /> >> + <arg name="id" type="new_id" interface="zwp_colorspace_v1" /> >> + </request> > > This should probably take length + offset, and note explicitly whether > it requires NULL termination or not, and how that relates to the size. > Our experience with xkbcommon was that _not_ NULL-terminating was > ideal.
Color spaces are binaries. So NULL-termination might not apply? >> + <request name="blending_colorspace"> >> + <description summary="tell the client what blending space is used"> >> + This request returns a zwp_colorspace_v1 object for the blending >> color >> + space of the compositor. All surfaces are converted by the >> compositor >> + to the blending color space before the blending operations. Once the >> + blending is performed, a further color conversion to the output >> color >> + spaces is carried out by the compositor. >> + A client should render in the blending color space returned by this >> + request if it does any color conversion on its own. This allows the >> + compositor to skip the color conversion to the blending color space. >> + </description> >> + <arg name="id" type="new_id" interface="zwp_colorspace_v1" /> >> + </request> > > This might be a stupid question, but is the blending colourspace > constant, or could it feasibly be changed if you had, e.g., outputs > with different characteristics? I understand that blending in linear > space is a must, but are there other considerations in play which > could suggest multiple 'blending spaces' for a single compositor? (I > would expect that if the blending space was to be constant across > outputs, then it should also be statically derivable by clients, > making this event redundant.) PDF, SVG2 require handling of different blending color spaces. So the interface appears to be useful. >> + <request name="output_colorspace"> >> + <description summary="returns the color space for the requested >> output"> >> + This request returns a zwp_colorspace_v1 object for the requested >> + output. A client can use this when it does not want its surfaces to >> be >> + color-corrected. In this case it can attach the color space of its >> main >> + output to its surfaces. >> + </description> >> + <arg name="output" type="object" interface="wl_output" /> >> + <arg name="id" type="new_id" interface="zwp_colorspace_v1" /> >> + </request> > > If a client doesn't want its surfaces to be colour-corrected ... won't > the compositor still convert into blending space and back (not > necessarily a lossless operation), if blending is required? Likely. My concern is that input == output color space => NULL conversion is flacky. A explicite opt out of color correction would be much appreciated. Kai-Uwe _______________________________________________ wayland-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/wayland-devel
