[PATCH] protocol: Add buffer_scale to wl_surface and wl_output
Alexander Larsson
alexl at redhat.com
Tue May 14 05:51:59 PDT 2013
On tis, 2013-05-14 at 13:44 +0200, John Kåre Alsaker wrote:
> 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.
I don't quite understand what you mean by this (like, how is "window"
different from "surface"). Can you give an example of how the API would
look for what you mean.
> 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.
I think a done event is silly, as it is not needed and complicates
clients (since the done event is not always sent for older servers), but
sure I can add one.
> 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
>
>
More information about the wayland-devel
mailing list