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

[Pekka Paalanen]

On Mon, 20 May 2013 17:58:30 -0700
Bill Spitzak <spitzak at gmail.com> wrote:

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

As far as I understand, that is correct.

But it does not matter. You cannot employ any widgets or widget parts
that would need a finer resolution than 100 px steps, because a) the
user cannot clearly see them, and b) the user cannot clearly poke them
with e.g. a pointer, since they are so small. So there is no need to
have window size in finer resoution either. Even a resize handle in a
window border would have to be at least 300 pixels thick to be usable.

The scale factor only allows to specify the image in finer resolution,
so it looks better, not jagged-edged for instance. There is no point in
having anything else in finer resolution, since everything else is
related to input.

To be precice, in that scenario a client should never even attempt to
make a buffer of 10050 px wide.

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

How can you say that? Where did you get the specification of how scaler
interacts with buffer_scale? We didn't write any yet.

And what is this talk about parent surfaces?

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

Yeah. So how does that define anything about scaler and buffer_scale
interaction?

The only thing that that could imply, is that buffer_scale and
buffer_transform are applied simultaneously (they are orthogonal
operations), so I can't understand how you arrive at your conclusion.

The scaler transformation was designed to change old surface
coordinates into new surface coordinates, anyway, except not in those
words, since it does not make sense in the spec.

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

Any size for buffer, okay.

How could you ever arrive to non-integer buffer sizes in the earlier
proposal?

Aligning sub-surfaces is still possible if anyone cares about that, one
just have to take the scale into account. That's a drawing problem. If
you had a scale 1 output and buffers, you cannot align to fractional
pixels, anyway.

Why would pre-compositing not be possible is some case?

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

Urgh, so you specify input region in one coordinate system, and then
get events in a different coordinate system? Utter madness.

Let's keep everything in the surface coordinates (including client
toolkit widget layout, AFAIU), except client rendering which needs to
happen in buffer coordinates, obviously. That is logical, consistent,
and easy to understand. That forces the clients to deal with two
coordinate systems at most, and application code that uses a toolkit
will deal mostly with just one coordinate system: the surface
coordinates. And this is what Alex's proposal does in my view.

Btw. what is the "output space"? It cannot be the output coordinate
system, since we do not expose that to clients, the same with the global
coordinate system. Having input in output coordinates does not make
sense anyway, because it becomes ill-defined when a surface crosses
multiple outputs.

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

WTF? How did you invent that? That is so wrong.

For the record, there cannot be any configure events for sub-surfaces,
therefore there cannot be any parent in the sub-surface sense. Want to
know why? Read the protocol and think for a bit.

Either that, or I have no idea what parent you are talking about. And
what about surfaces without a parent?

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

No, it is in the surface coordinate system, like written in the patch.

- pq