<div dir="ltr"><div>My proposal is simply to let the compositor tell the client how much larger it wants the client to render content. The client can then tell the compositor how much larger it made content in the window. Armed with this information the compositor can size the window accordingly.</div>
<div><br></div><div>Note that this implies no further change in the protocol or concepts. Surface coordinates are still of the same size as buffer coordinates.</div><div><br></div><div>This has a number of benefits over the current implementation:</div>
<div>+ Rational scaling factors has no issues (the most important benefit).</div><div>+ Output sizes do not have to be a multiple of the scaling factor. </div><div>+ Clients can specify their size in pixels exactly.</div>
<div>+ Clients get input in exact pixels (no rounding errors).</div><div>+ Clients doesn't have to transform input events in order to match the sizes used by buffers.</div><div>+ Conceptually simple to implement. Compositors doesn't have to deal with scaling for subsurfaces and they are probably already able to resize whole windows.</div>
<div>+ Can support clients with integer scaling factors, although these raises the same edge cases as the current implementation (they may not be able to fit the screen exactly).</div><div><br></div><div>There are however some downsides:</div>
<div>- Clients may need to transform input events in order to match the coordinates used by applications.</div><div>- Clients changing scaling factors will have older input reported in the old size. This will be quite rare although clients can deal with it if desired.</div>
<div>- Requires an implementation <:)</div><div><br></div><div>I don't expect GTK or other (ancient) toolkits to do fractional scaling and reap all the benefits listed here. I don't want anything in the core protocol blocking the ability for clients to scale smoothly up though when clients will actually be able to do this.</div>
</div>