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

Alexander Larsson alexl at redhat.com
Wed May 8 08:07:25 PDT 2013


On ons, 2013-05-08 at 10:43 -0400, Todd Showalter wrote:
> On Wed, May 8, 2013 at 6:51 AM,  <alexl at redhat.com> wrote:
> 
>     There are problems with this.
> 
>     We're moving to a "HiDPI" world.  With 3DTV failing in the market,
> it's looking like the TV manufacturers are going to push hard on 4K,
> and once 4K panels are widely available they'll work their way down to
> PCs fairly quickly.  By the time Wayland is moving into mainstream
> adoption, if 4K isn't the standard yet for 20" - 24" monitors it will
> be imminent.

I disagree, external monitors will be not be commonly HiDPI for a long
time, so having a mix of "Hi" and "Low" DPI monitors will be common for
a long time.

>     We're at that point in iOS now; with the exception of legacy
> hardware, the iPad Mini and the (presumably soon to be discontinued)
> iPad 2, everything is "retina" and has a 2.0 scale factor.  We're
> probably less than a year away from the end of Apple selling any iOS
> devices with a 1.0 scale factor, and two to three years at most from
> the point where support for 1.0 scale devices is a consideration for
> developers.  Apple needed something to bridge the gap between the
> devices, but that gap is just about behind us now, and the scale
> factor is going to remain as a minor programming wart for a long time
> to come; something that trips up new developers.

I don't think we can assume everything is high dpi for a loong time.
There is both the external monitor case and old/non-apple hardware to
consider. So apps and things like themes must specify coordinates in a
scaled coordinate space, or things will just not work on hidpi displays
(i have one, its unusable without it). And, for various technical as
well as visual (non-aligned/integer width borders in e.g. buttons look
*really* bad) we need this scaling factor to be an integer.

>     Windows blew it with their DPI adjustments; in my experience
> changing the DPI significantly on Windows (up to and including win7)
> breaks things.  Even OS tools render wrong, and many times I've run
> into games that don't handle mouse positions properly when the DPI is
> changed.  If you run Stardock's Fallen Enchantress at double DPI, for
> example, the mouse pointer can move across the entire screen, but as
> far as the game is concerned the actual location of the pointer is
> scaled by 0.5, constrained to the upper left quarter of the screen.
> This is not an uncommon problem.

This is due to the way microsoft handled this, enforcing apps to do the
scaling. This solution is completely different. All input will be
pre-scaled and appear in "lodpi", and upscaling will be fully automatic
by wayland and/or the toolkit.

>     The angle subtended by a pixel to the viewer is the problem.

I disagree. I mean, in practice that is what any kind of DPI boils down
to, yes. But its not the *problem*. The problem is that we don't have
any way to cope with large changes in this value. For a traditional
setup you'd have multiple monitors with somewhat different DPIs, but
it'd still work pretty well because the angular density was
approximately the same. But suddenly we have displays where the
resolution is large enough that it matters, your 1 pixel button borders
become almost invisible. This is what we need to fix, not magically
match exact scale factors so that your 1 angular degree wide line is
exactly 1 angular degree wide on another display.

Its true that the monitor DPI itself doesn't necessarily map directly to
whether the monitor is HiDPI or not. We may very well need to scale the
UI up on your 46" TV, but that can be done as well with buffer scaling,
and it will work automatically with all apps, and scale
icons/borders/padding, etc as well as fonts.

>     Ultimately, the answer may just be to do what you're planning and
> make sure that there's some sort of simple tool to let the user set
> their view distance.  Whatever we do, though, it needs to deal with
> this problem.

Exactly. The compositor is in full control of the buffer scale for any
output, so users will be able to override it.




More information about the wayland-devel mailing list