[PATCH 2/2] protocol: Support scaled outputs and surfaces

[Bill Spitzak]

Pekka Paalanen wrote:

>> This seems pretty limiting to me. What happens when *all* the outputs 
>> are hi-res? You really think wayland clients should not be able to take 
>> full advantage of this?
> 
> Then the individual pixels are so small that it won't matter.

It does not matter how tiny the pixels are. The step between possible 
surface sizes and subsurface positions remains the size of a scale-1 
unit. Or else I am seriously mis-understanding the proposal:

Let's say the output is 10,000dpi and the compositor has set it's scale 
to 100. Can a client make a buffer that is 10,050 pixels wide appear 1:1 
on the pixels of this output? It looks to me like only multiples of 100 
are possible.

>>> If nothing else it makes it so that subsurfaces are
>>> always positioned on integer positions on non-scaled displays, which
>>> makes things easier when monitor of differen scales are mixed.
>> This is false if the subsurface is attached to a scaled parent surface.
> 
> Huh?

Parent surface uses the scaler api to change a buffer width of 100 to 
150. The fullscreen and this hi-dpi interface can also produce similar 
scales. The subsurface has a width of 51. Either the left or right edge 
is going to land in the middle of an output pixel.

>> The input rectangle to the scaler proposal is in the space between the 
>> buffer transform and the scaling. Therefore there are *three* coordinate 
>> spaces.
> 
> Where did you get this? Where is this defined or proposed?

The input rectangle is in the same direction as the output rectangle 
even if the buffer is rotated 90 degrees by the buffer_transform.

> On a quick thought, that seems only a different way of doing it,
> without any benefits, and possibly having cons.

Benefits: the buffer can be any integer number of pixels in size, 
non-integer buffer sizes cannot be specified by the api, you can align 
subsurfaces with pixels in the buffer (which means a precomposite of 
subsurfaces into the main one before scaling is possible).

> Actually, it means that the surface coordinate system can change
> dramatically when a client sends a new buffer with a different scale,
> which then raises a bucketful of races: is an incoming event using new
> or old surface coordinates? That includes at least all input events
> with a surface position,

This is a good point and the only counter argument that makes sense.

All solutions I can think of are equivalent to reporting events in the 
output space, the same as your proposal. However I still feel that the 
surface size, input area, and other communication from client to server 
should be specified in input space.

> and the shell geometry event.

Geometry is in the space of the parent surface, not this surface. This 
is true in both proposals. Both would get exactly the same geometry events.

> For the record, wl_surface.attach changes the surface coordinate system
> by translating with x,y, but that is not a problem. The x,y do not
> describe how the surface moves, they describe how pixel rows and
> columns are added or removed on the edges.

If x,y is in buffer pixels then it matches my proposal. It can change 
the results of the scaler to non-integers then, so I was under the 
impression it would be ignored in this case. Assuming logical use of the 
hi-dpi I don't see a problem with it being in buffer pixels then.