[RFC wayland-protocols v3 1/1] unstable: add color management protocol

[Pekka Paalanen]

On Tue, 2 Apr 2019 13:13:17 +1100
Graeme Gill <graeme2 at argyllcms.com> wrote:

> Sebastian Wick wrote:
> 
> > +<protocol name="color_management_unstable_v1">  
> 
> > +  <interface name="zwp_color_manager_v1" version="1">  
> 
> > +    <request name="get_color_management_surface">
> > +      <description summary="create a color management surface from a wl_surface">
> > +	This creates a new color zwp_color_management_surface object for the
> > +	given wl_surface.
> > +
> > +	See the zwp_color_management_surface interface for more details.
> > +      </description>
> > +      <arg name="id" type="new_id" interface="zwp_color_management_surface_v1"/>
> > +      <arg name="surface" type="object" interface="wl_surface"/>
> > +    </request>  
> 
> > +  <interface name="zwp_color_management_surface_v1" version="1">
> > +    <description summary="set color management information of a surface">
> > +	A zwp_color_management_surface allows the client to set the color space and
> > +	HDR properties of a surface.
> > +    </description>  
> 
> > +    <request name="set_color_space">
> > +      <description summary="set the color space">
> > +	Set the color space of the underlying surface. The color space is double
> > +	buffered, and will be applied at the time wl_surface.commit of the
> > +	corresponding wl_surface is called.  
> 
> Hi,
> 	source color space is not an attribute of a wl_surface
> though, it is an attribute of a wl_buffer, the same as (implied) dpi
> and format.

Hi Graeme,

yes, it is not an attribute of wl_surface, but it also is not an
attribute of a wl_buffer. It is an attribute of the current contents in
a wl_buffer, contents that will get transferred into the wl_surface on
commit (by reference or by copy). In essence, the color space is a
property of the commit (wl_surface.commit). The proposed extension
language models that mechanism correctly by referring to
"double-buffered state". I can't think of better wording for this, the
term double-buffered state has grown that special meaning when talking
about Wayland.

More precisely, a wl_buffer is a chunk of memory with a size and pixel
format, and they get re-used all the time. If a client changes the
color properties of the content but not the pixel format, it likely
will not allocate a new wl_buffer to hold it. All client frameworks aim
to re-use existing buffers as much as they can, because destroying and
allocating new ones takes effort.


Thanks,
pq
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20190402/dc082761/attachment.sig>