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

[Pekka Paalanen]

On Fri, 17 May 2013 12:06:35 -0700
Bill Spitzak <spitzak at gmail.com> wrote:

> Alexander Larsson wrote:
> 
> > You can make a surface of any integer size (and it has to be integer due
> > to existing APIs on surface coordinates/sizes), however the *buffer* has
> > to be an integer multiple of the surface size. In other words, surface
> > sizes and positions are described in the global compositor space, with
> > integer sizes.
> 
> 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.

If the pixels are not small enough to not matter, then you just set
scale=1 to everything, and the image it still legible.

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

> > I see it the other way. We currently have *two* coordinate spaces that
> > the client has to think about. The buffer coordinates (it has to know
> > this when rendering), and the surface coordinates (these are basically
> > what all wayland APIs atm use, like in damage, positioning and input).
> > The transform between two is currently the buffer_transform only. With
> > the buffer_scale the transform is extended to also scale, but no
> > additional coordinate space is added.
> 
> 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?

> My proposal is that "surface space" be moved before the scaling. This 
> reduces the number of spaces back to two by using the same space for 
> input rectangle as for events and surface size, etc. It also means 
> integers always have a physical meaning for the client (ie buffer 
> pixels) and that odd-sized buffers are supported on the hi-res display.

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

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, and the shell geometry event.

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. This means that the content
is presumed to stay put on screen. It's also hard to click a specific
point in a window whose size is changing, and the translation is not
dramatic. Even when one might claim that attach has the same problem as
your proposal, in practice it does not.

- pq