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

[John Kåre Alsaker]

On Mon, May 13, 2013 at 11:56 AM, Alexander Larsson <alexl at redhat.com>wrote:

> 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.
>
The scaling factor should not have any affect of any coordinate system or
anything else in the protocol. It should only affect the size in pixels of
the surfaces of the clients. Clients should do any transformations of
coordinates they want themselves.


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


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

I think the case when a window is displayed on multiple monitors is pretty
rare or short in duration (the dragging across monitor case when not using
a workspace per monitor). I suppose we could leave this up to the
compositor.

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20130513/f654cf2b/attachment.html>