Hi Kai-Uwe, On 20 December 2016 at 14:46, Kai-Uwe <ku.b-l...@gmx.de> wrote: > Am 20.12.2016 um 15:25 schrieb Daniel Stone: >> On 19 November 2016 at 16:29, Niels Ole Salscheider >>> + <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.
I'm not quite sure how this response relates to my question, unless you are discussing a Weston compositor which targets PDF and/or SVG. In Niels's strawman proposal, there is only _one_ blending colourspace for _every_ blending operation performed in the _entire_ compositor. This means that the blending colourspace must be independent of the output devices; in this case, it is relatively easy to replace this with a single fixed colourspace. If there was a per-output blending colourspace (as well as final display colourspace), that would make a great deal more sense to me. >>> + <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. What does an explicit opt-out actually mean? Does it mean that the compositor assumes sRGB? Linear? That a NULL transform is applied when scanning out directly from that surface? When going through a GPU composition pipeline, is the inverse transform from the output colourspace to blending colourspace, or does 'opt out' mean that blending is performed directly in the target colourspace? I'm also curious as to what you mean by it being flaky. Cheers, Daniel _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
