[PATCH 0/2] Support for high DPI outputs via scaling

[Alexander Larsson]

On ons, 2013-05-08 at 14:51 -0500, Jason Ekstrand wrote:


>             Is there a way to bypass the scaling?  When I'm using the
>         mouse in
>         a game, I want to know the pixel position of the pointer, with
>         no
>         scaling applied.  I'm going to be drawing the gui at native
>         res, and I
>         want the mouse to interact with it at native res.
>
> I think that's supposed to be solved by wl_pointer giving sub-pixel
> accuracy.

Yeah, input will have (already has) sub-pixel accuracy, so you need only
handle that.

> I don't know that I'm opposed to some sort of scaling factor on
> principle.  Android has pixels (px) vs. display pixels (dp) and that
> seems to work fairly well.  I guess I'm still a little confused as to
> exactly what roles the compositor and the toolkit play and what the
> "scaling factor" means.  Is the compositor's part simply to scale the
> surface for the lower/higher res monitor?

On a wl_output, a scaling factor of means that the mapping from surface
coordinates/size to the output framebuffer scales the content of a
"normal" surface by 2. Its very similar to the existing transform method
with can say that when outputting a buffer its content will be rotated
90 degrees.

Similarly, scaling factor on a surface is very much like the existing
buffer_transform on the window. It says that this window is already
pre-scaled (vs. pre-rotated) by the amount specified. If the surface
scaling and rotation matches what the output has then we don't need to
apply the scaling/rotation. It also means that the client can supply
subpixel precision which would not be available if the server had to do
the upscale.

If the surface doesn't have the right scaling factor, then the
compositor needs to scale the surface up or down while rendering it to
the output.

> Also, what happens if you have three monitors with factors 1, 2, and
> 3?  Can you render at 2 or 3?  I guess I'm concerned that we're going
> to lock ourselves into a system where monitor sizes have to come in
> powers of 2 or we won't be able to make sense of them.  Then again,
> there may be no better solution.

I'm not sure what you think is a problem with having these factors? Its
not any different from the current state with 3 monitors at 3 different
rotations. The client supplies *one* buffer for the surface, and it
picks the scaling factor for it. The compositor then has to scale it the
right amount when rendering it on any particular monitor. Generally the
app will track which output the window is "mostly on" and use that to
determine what resolution to pick for the buffer, but it must always
handle that a window can overlap multiple outputs, so the compositor
needs to be able to render it at multiple sizes.

There is some ambiguity in the case of mirrored outputs at different
scales. What resolution should the client pick then? If we pick the
larger one it will look better on the higher resolution one, and if we
pick the smaller it will look better on the lower resolution one. Both
are valid choices, depending on how you are using the displays, so this
should imho be up to the user. In order to allow the compositor to tell
the client of the user choice I added the output priority field to the
geometry.

> For reference, this has already been discussed at some length on the
> list.  The first post to the effect is here:
> http://lists.freedesktop.org/archives/wayland-devel/2013-March/007941.html

When I first showed my HiDPI work to kristian he said that we could also
allow a client to supply per-output buffers for the surface so that a
window overlapping two monitor of different scale could look good in
both.

There is certainly nothing wrong about that, and we could allow it.
However, I think it is severe overkill. Very few windows span monitors,
and I don't think any toolkits will take advantage of this (in fact, it
would be hard to make this work reliably in Gtk+ due to how the widget
APIs work). Making the client pick a single format seems good enough in
practice.

> Also, we need to figure out how this interacts with the proposed
> scaling extension.  Information can be found here:
> http://lists.freedesktop.org/archives/wayland-devel/2013-April/008927.html

I don't think it needs much extension. It works as is, although the docs
refering to wl_surface.set_buffer_transform also needs to mention the
scaling factor.

Of course, there is also the question of if we could use the
wl_surface_scaler interface to do the HiDPI scaling. And, while this
would be technically possible it seems the wrong approach to me. The
surface scaler API is much more demanding of the compositor with
non-integer scaling factors, cropping and aspect ratio changing. I don't
think we want to force compositors to always support all of that in
order to work on HiDPI displays where a much simpler subset is needed.
Also, its a much more complex API to use for something so basic that
every window will use it.

Basically, wl_surface_scaler is for scaling of subsurfaces with video,
and I don't think we should mix the two up.