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, <al...@redhat.com> wrote: > > From: Alexander Larsson <al...@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@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/wayland-devel > > _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel