Hello Daniel, Am 20.12.2016 um 17:44 schrieb Daniel Stone: > 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.
I am talking about source documents, which might be PDF or SVG. And in these the blending space can change. So a Wayland client might draw each PDF/SVG element to a Wayland surface and would come in need to switch the blending space for rendering the document. Doing it all in Wayland makes the server much more powerful. > In Niels's strawman proposal, there is only _one_ blending colourspace > for _every_ blending operation performed in the _entire_ compositor. Ah ok. So take my comment as the hint for a possible use case for multiple blending spaces ;-) >>>> + <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? From the main use case of drawing channel values unaltered to the output, I would say the later. That is as well the current behavior, without any color correction and changed happening only while blending. There is no gamma conversion, no color space conversion. The conflict might be that blending ops work currently best for gamma encoded values and might be changed to work for linear gamma 1.0 . The transition from a gamma image to convert to linear gamma for blending should not be noticeable, perhaps measurable. Further there is the need to copy the surface for blending to linear gamma. For this case, do not touch the values, it appears appropriate. > I'm also curious as to what you mean by it being flaky. Flaky - the client cant not know what happens to its values as output==output => NULL is a implicit rule. It might be optimised out or whatever at will of the server and the client is a real looser as it is only a weak suggestion. A Do Not Touch (or opt out) marker is pretty clear to everyone and the client can assume to remain in control like with a contract. Kai-Uwe _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
