[PATCH 00/15] weston scaling support

[Pekka Paalanen]

On Tue, 28 May 2013 19:27:35 +0200
John Kåre Alsaker <john.kare.alsaker at gmail.com> wrote:

> 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.

How would this look in protocol? Just roughly, what requests and events
would be involved. Especially, how does the compositor know to suggest
a size?

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

Alright.

> This has a number of benefits over the current implementation:
> + Rational scaling factors has no issues (the most important benefit).

I think they may have issues. A surface pel may not cover an integer
amount of pixels in both buffer and output. Or how do you arrange that?

For crisp pel-sized graphics (pixel-sized in apps that do not
understand the output scale), a pel should be an integer amount of
pixels in both output and buffer.

> + 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.

I don't really get the above.

> + Conceptually simple to implement. Compositors doesn't have to deal with
> scaling for subsurfaces and they are probably already able to resize whole
> windows.

Why would sub-surfaces have any effect here?

> + 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.

So this is a minus here, but the same wrt. buffers was a plus. And it's
the application that first deals with input events, and then decides
what to draw. I don't think input goes directly to drawing machinery.

> - 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.

You listed some features, but I still have no idea what you are
suggesting.

It also seems the integer output scale proposal and implementation are
maturing nicely, so now there would need to be obvious reasons for
changing it. I just don't see it based on this description.

- pq