[PATCH 00/15] weston scaling support

[Bill Spitzak]

It appears John Alsaker is proposing exactly the same change I have been 
proposing. I think we are having a hard time explaining it however.

Pekka Paalanen wrote:
> 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?

It would look *EXACTLY* the same as how the compositor currently tells 
clients about the output scale.

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

In John's proposal a "pel" *EQUALS* a buffer pixel. It is always an 
integer number of pixels in buffer space, no matter what scale is 
chosen. The fact that you don't see this means that somehow John is not 
explaining his design well enough, and perhaps that is why there is 
resistance to it? But it seems pretty obvious to me.

The current scale proposal allows a "pel" to be a non-integer in both 
buffer and output space. The easiest way is to put a surface with a 
scale of 3 on an output with a scale of 2.

>> + Output sizes do not have to be a multiple of the scaling factor.

I think this may be useful for tablets? But it turns out that large 
monitor sizes have been designed to allow integer scales of smaller 
sizes. For instance 1920x1080 has common factors of 2,2,2,3,5, meaning 
any integer scale that is a multiple of any set of those factors will work.

However if there is any kind of "panel" on the edge of the monitor there 
are going to be problems with maximized windows because the reduced size 
is going to have much fewer factors, or the panel is going to be 
restricted to large increments in size that may mean only ugly sizes are 
possible.

>> + Clients can specify their size in pixels exactly.

The biggest problem with the scale proposal is that the sizes and 
positions of windows are restricted to visibly large steps, thus 
defeating the whole point of high-dpi displays.

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

You said "pels" don't match buffer pixels. Therefore a transformation is 
needed to get to buffer pixels. And I'm worried that high-resolution 
pointing devices will be ignored by clients that immediately round to 
the nearest buffer pixel.

> I don't really get the above.

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

I think the assumption that the application is working in "pels" is 
simplistic. We *KNOW* that part of the application is working in buffer 
pixels (ie the drawing code). It should use a coordinate system that is 
known to mean something to the application.

>> - 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 <:)

This seems to be the biggest actual objection, other than apparent 
misunderstanding of the proposal.

However the same problem applies for when a buffer attach is done with 
an x and y offset. The client does not know exactly what mouse events 
are pointing at unless it knows whether they are before or after the commit.

So I now think a better solution is to have the compositor echo the 
commit in the event stream, so the client can easily tell whether events 
are before or after it. It is possible that existing events can be used 
to determine this.

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

I think is is incredibly obvious what the advantages of his scheme are. 
The fact that you cannot see it is really mystifying.