[PATCH 00/15] weston scaling support

[John Kåre Alsaker]

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.

Note that this implies no further change in the protocol or concepts.
Surface coordinates are still of the same size as buffer coordinates.

This has a number of benefits over the current implementation:
+ Rational scaling factors has no issues (the most important benefit).
+ Output sizes do not have to be a multiple of the scaling factor.
+ Clients can specify their size in pixels exactly.
+ Clients get input in exact pixels (no rounding errors).
+ Clients doesn't have to transform input events in order to match the
sizes used by buffers.
+ Conceptually simple to implement. Compositors doesn't have to deal with
scaling for subsurfaces and they are probably already able to resize whole
windows.
+ 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).

There are however some downsides:
- Clients may need to transform input events in order to match the
coordinates used by applications.
- 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.
- Requires an implementation <:)

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20130528/a7e2c259/attachment.html>