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

[Alexander Larsson]

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

>         > Clients can easily scale larger features like icons, padding
>         and fonts
>         > and round them to pixel sizes and draw sharp output even
>         with a
>         > fractional scaling factor. This allows users to pick a size
>         suitable
>         > for them. The difference between a 1 and 2 scaling factor is
>         too huge.
>         
>         
>         Some things can be easily scaled. Like text and photorealistic
>         images.
>         Other things can't necessarily be scaled and still look nice.
>         Like line
>         art or solid line borders (like e.g. the boxes around a
>         button). Sure,
>         you can round everything to "nearest int", but that will cause
>         unevenness in the rounding (buttons sometimes get a 1 pixel
>         border,
>         sometimes 2 depending on the fractional part of the button
>         coords, etc).
>         So, I don't think this is every useful in practice.
> Even if things aren't perfectly even, it will still be much better
> than the alternative which is round up to the next scaling factor and
> let the compositor scale the surface down to a suitable size again.
> This is what you have to do on Mac OS X to get a reasonable workspace
> on higher DPI displays. Windows gets 4 times bigger from scaling
> factor 1 to 2. That isn't near enough granular.

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.

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.

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