On Tue, 2 Apr 2019 13:13:17 +1100
Graeme Gill <[email protected]> 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

Attachment: pgpilHul6WVl1.pgp
Description: OpenPGP digital signature

_______________________________________________
wayland-devel mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Reply via email to