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

[Alexander Larsson]

On mån, 2013-05-13 at 14:40 +0200, John Kåre Alsaker wrote:

>         
>         I don't think this will work in practice. I know for sure that
>         e.g. Gtk
>         is not set up to do any reasonable non-integer scaling. It
>         will just
>         scale up all drawing by a fractional factor without any
>         rounding
>         anywhere, causing everything to become fuzzy. We will
>         eventually have
>         alternative icons for higher resolutions, but these will be at
>         2x scale,
>         not at generic fractional factor (that is not really doable
>         without
>         using pure-vector icons with some complex hinting method).
>         Although, I
>         guess that in the case of text the scaling will be ok, so for
>         some
>         usecases it might be OK.
> It will work very well for things designed to be scalable, browsers
> are an example. GTK could just fall back to integer scaling.

Browsers are not really scalable like that, css page layout is generally based on
the CSS "Px" definition, and per e.g.
http://static.zealous-studios.co.uk/projects/web_tests/PPI%20tests.html:

        For lower-resolution devices [i.e. non-print], and devices with unusual
        viewing distances, it is recommended instead that the anchor unit be the
        pixel unit. For such devices it is recommended that the pixel unit refer
        to the whole number of device pixels that best approximates the
        reference pixel.

I.e. "whole number of pixels" => scale by integer matches best what CSS wants.

>         So, it's my opinion that supporting fractional scaling is an
>         unnecessary
>         burden on compositors for something that is not very useful in
>         practice.
>         Thats just my opinion though, and the proposal as such can
>         handle
>         fractional scaling fine by just changing the scale factors to
>         fixed
>         type.
> It is of no burden on compositors at all, only for clients which
> choose to implement it.

It is, as long as clients are allowed to specify a fractional scaling
factors compositors need to be able to handle scaling by that (for
instance if the window appears partially on a non-highres monitor.

>         > In mirrored/clone mode only a single wl_output would be
>         presented to
>         > clients with a single scale factor, so priorities won't
>         matter in that
>         > case.
>         
>         
>         That is not necessarily so. We might very well want to know
>         that there
>         are two displays, with say different RGB subpixel order, etc.
> The compositor could unify this information into a single wl_output.

And what would it then report for physical width/height, subpixel, make,
model, etc? Seems pretty weird.

> I suggest we send 3 scaling factors to clients. A lower bound where
> factors lower will be scaled up. The desired scaling factor. A upper
> bound where factors above will be scaled down. Clients should find the
> scaling factor in lower bound to upper bound they are able to render
> at which is closes to the desired factor. Failing that they should
> find the first factor they are able to render at above the upper
> bound. When displayed on multiple monitors it could try to remain
> sharp on as many monitors as possible.

I don't quite understand this. Any factor lower than the "desired"
factor has to be scaled up, no?

Lets take a concrete example. The macbook pro 15" has a 2880 x 1800
native panel. This is "normally" driven as 1440 x 900 with a scale
factor of 2. On OSX you can also select a 1920x1200 resolution, which is
nominally a scale factor of 1.5. However, on OSX what they do is that
apps render to a framebuffer at twice the resolution (3840x2400) and its
then scaled it down to 2880x1800 to make it look reasonable.

On such a setup in wayland the wl_output would be 1920x1200, with a
scaling factor of 1.5. For a 800x601 window a hidpi applications could
then either pick a buffer of 1600x1202 buffer and set a scaling factor
of 2 causing the compositor to downscale it (similar to OSX above), or
it could create a buffer at 1200x902 (nearest to the true 901.5) and and
set scaling factor to 902/600 (i.e. 1.50333..) and have the compositor
not scale it (which is a minor issue due to the 1.5 != 1.50333..).

In this case the desired scaling factor would be 1.5. What do you expect
the upper and lower bounds to be?