[PATCH] protocol: Add buffer_scale to wl_surface and wl_output

Tue May 14 04:44:27 PDT 2013

I'd only accept a proposal which makes the clients tell the compositor how
much they increased the size of their window. If the compositor wants to
resize anything it should resize the entire window and not individual
surfaces/buffers. This also avoids having to position subsurfaces and have
configure requests at fractional surface pixels.

set_buffer_scale should be renamed to set_scaling_factor. Otherwise it
could be easily confused with the scaling extension which just scales up
buffers. My suggestion also renders it unrelated to buffers. The geometry2
event should be named scaling_factor. A done event should also be added.
I'd also like a lower and upper bound for the scaling factor as argument to
that.

On Tue, May 14, 2013 at 12:26 PM,  <alexl at redhat.com> wrote:

> From: Alexander Larsson <alexl at redhat.com>
>
> This adds wl_surface_set_buffer_scale() to set the buffer scale of a
> surface.
>
> It is similar to set_buffer_transform that the buffer is stored in a
> way that has been transformed (in this case scaled). This means that
> if an output is scaled we can directly use the pre-scaled buffer with
> additional data, rather than having to scale it.
>
> It also adds a geometry2 event with a scale member to wl_output that
> specifies the scaling of an output.
>
> This is meant to be used for outputs with a very high DPI to tell the
> client that this particular output has subpixel precision. Coordinates
> in other parts of the protocol, like input events, relative window
> positioning and output positioning are still in the compositor space
> rather than the scaled space. However, input has subpixel precision
> so you can still get input at full resolution.
>
> This setup means global properties like mouse acceleration/speed,
> pointer size, monitor geometry, etc can be specified in a "mostly
> similar" resolution even on a multimonitor setup where some monitors
> are low dpi and some are e.g. retina-class outputs.
> ---
>  protocol/wayland.xml | 41 +++++++++++++++++++++++++++++++++++++++--
>  1 file changed, 39 insertions(+), 2 deletions(-)
>
> diff --git a/protocol/wayland.xml b/protocol/wayland.xml
> index 3bce022..e5744c7 100644
> --- a/protocol/wayland.xml
> +++ b/protocol/wayland.xml
> @@ -876,7 +876,7 @@
>      </event>
>    </interface>
>
> -  <interface name="wl_surface" version="2">
> +  <interface name="wl_surface" version="3">
>      <description summary="an onscreen surface">
>        A surface is a rectangular area that is displayed on the screen.
>        It has a location, size and pixel contents.
> @@ -1110,6 +1110,30 @@
>        </description>
>        <arg name="transform" type="int"/>
>      </request>
> +
> +    <!-- Version 3 additions -->
> +
> +    <request name="set_buffer_scale" since="3">
> +      <description summary="sets the buffer scale">
> +       This request sets an optional scaling factor on how the compositor
> +       interprets the contents of the buffer attached to the surface. A
> +       value larger than 1, like e.g. 2 means that the buffer is 2 times
> the
> +       size of the surface.
> +
> +       Buffer scale is double-buffered state, see wl_surface.commit.
> +
> +       A newly created surface has its buffer scale set to 1.
> +
> +       The purpose of this request is to allow clients to supply higher
> resolution
> +       buffer data for use on high-resolution outputs where the output
> itself
> +       has a scaling factor set. For instance, a laptop with a high DPI
> +       internal screen and an low DPI external screen would have two
> outputs
> +       with different scaling, and a wl_surface rendered on the scaled
> output
> +       would normally be scaled up. To avoid this upscaling the app can
> supply
> +       a pre-scaled version with more detail by using set_buffer_scale.
> +      </description>
> +      <arg name="scale" type="fixed"/>
> +    </request>
>     </interface>
>
>    <interface name="wl_seat" version="1">
> @@ -1467,7 +1491,7 @@
>      </event>
>    </interface>
>
> -  <interface name="wl_output" version="1">
> +  <interface name="wl_output" version="2">
>      <description summary="compositor output region">
>        An output describes part of the compositor geometry.  The
>        compositor works in the 'compositor coordinate system' and an
> @@ -1520,6 +1544,8 @@
>         The geometry event describes geometric properties of the output.
>         The event is sent when binding to the output object and whenever
>         any of the properties change.
> +
> +        Some additional properties were later added, see
> wl_output.geometry2.
>        </description>
>        <arg name="x" type="int"
>            summary="x position within the global compositor space"/>
> @@ -1565,6 +1591,17 @@
>        <arg name="height" type="int" summary="height of the mode in
> pixels"/>
>        <arg name="refresh" type="int" summary="vertical refresh rate in
> mHz"/>
>      </event>
> +
> +    <event name="geometry2" since="2">
> +      <description summary="additional properties of the output">
> +       This event contains additional geometric information
> +        that are not in the geometry event. Whenever it is sent
> +        it will be followed by a geometry event. This way you can
> +        tell by the time the geometry event is recieved whether a
> +        geometry2 event will be seen or not.
> +      </description>
> +      <arg name="scale" type="fixed" summary="scaling factor of output"/>
> +    </event>
>    </interface>
>
>    <interface name="wl_region" version="1">
> --
> 1.8.1.4
>
> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20130514/e31f6343/attachment.html>