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

[Alexander Larsson]

On ons, 2013-05-08 at 22:58 +0200, John Kåre Alsaker wrote:
> I think we should allow fractional scale factors. Clients which only
> support integer scale factors should round the scale factor they get
> to a whole number.

I don't see how this is useful? The scaling has two main benefits:

1) It defines a common global coordinate system in which to specify
   global things like window sizes, mouse speed, pointer size, relative 
   monitor positions, etc. For these it doesn't necessarily matter that
   the DPI of these match exactly, only that they are "of the same
   magnitude". I personally have a desktop setup with two different
   monitors of different DPI, which works fine. However, I also have
   a chromebook pixel with 239 dpi, and using the same settings for
   these things *definately* is a problem on that.

2) It allows reusing all existing code and assets that specify things in
   pixels. The fact that the theme specifying a one-pixel border on
   buttons end up with a 3% wider line on some displays is not really 
   a problem. However, on the pixel it is again a real problem. Surface
   scaling lets us fix this without modifying and duplicating all widget
   code, themes, svgs, etc.

A fractional scale factor is always going to cause visually poor
experience due to nr 2. I.e. themes will use an integer multiple wide
lines and padding in order to look good on current resolution screens,
which will always end up looking blurry if you then scale by a fraction.
In fact, if the scaling factor is e.g. 1.5, there is no way for a theme
to get crisp button borders. It could specify a line of width 0.66666667
and hope it gets rounded to exactly 1 on the output, but if some padding
above it made it accidentally end up on an uneven row it would become
blurred between two rows on the screen.

It also causes issues because buffers are by necessity of integer sizes,
and an integer buffer size times a fractional scale will cause the
surface to have a fractional size in the global coordinate space. How
would you handle this if the window overlaps an output with a different
scaling factor? You'll end up with either a cut off window not showing
the last row or a blurred partial pixel rendered with AA. How would you
maximize a window when the interger output size results in a fractional
buffer size for the window?

> I don't think we need a scale priority on wl_outputs, clients should
> pick the highest scale factor of the outputs it's on.

I don't agree. This is a policy decision, as it will always result in
the best looking output on the highest dpi monitor. The lower one would
get a downscale of the hires rendering, which will look worse than e.g.
a properly hinted text rendered for the lower resolution, and I can
easily imagine situations where you want the output to look sharpest on
the lower resolution monitor, like when you're using a projector.

What to pick in this case should be up to the user and/or
compositor/desktop-environment, so we should allow the compositor to
tell clients what to do in this case. This is what e.g. OSX does (i.e.
you get a popup that asks if you want best looking result on the monitor
or on the laptop display).