<div dir="ltr">On Tue, May 14, 2013 at 2:51 PM, Alexander Larsson <<a href="mailto:alexl@redhat.com" target="_blank">alexl@redhat.com</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div class="im">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. </div>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. </blockquote><div>A window can have multiple surfaces (see the subsurface extension).</div><div> </div><div>The API would be the same, the documentation different.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div class="im"> > 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. </div>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. </blockquote><div>Clients can easily require a compositor which implements the done event, although they may also support older versions. It's just the compositor that has to take care not sending done (and geometry2) to the old clients.</div> <div> </div><div>If you add one, it should be in a separate commit as it's unrelated to this work.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div class="HOEnZb"><div class="h5"> > On Tue, May 14, 2013 at 12:26 PM, <<a href="mailto:alexl@redhat.com">alexl@redhat.com</a>> wrote: > > From: Alexander Larsson <<a href="mailto:alexl@redhat.com">alexl@redhat.com</a>> > > 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> > + > +  > + > + <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 > <a href="mailto:wayland-devel@lists.freedesktop.org">wayland-devel@lists.freedesktop.org</a> > <a href="http://lists.freedesktop.org/mailman/listinfo/wayland-devel" target="_blank">http://lists.freedesktop.org/mailman/listinfo/wayland-devel</a> > > </div></div></blockquote> </div>