High-DPI displays and Linux
High-DPI displays and Linux [LWN.net]


Benefits for LWN subscribers

The primary benefit from subscribing to LWN
       is helping to keep us publishing, but, beyond that, subscribers get
       immediate access to all site content and access to a number of extra
       site features.  Please sign up today!


Your editor's laptop recently started to fall apart, to the point that some
sort of action was required.  Duct tape was considered as a solution; it
would show that LWN is making careful use of its subscription
revenues, but would also convey an impression that is, arguably, not 100%
professional.  The alternative was to get a new laptop; that costs money,
but the idea turned out to be awfully shiny and distracting.  So your
editor ended up 
with a ThinkPad X1 Carbon.  This machine has a number of nice features and
a few weird quirks, but one of the more interesting options it came with is
a high-DPI, 2560x1440 display.  That was an ideal opportunity to
investigate the state of Linux support of high-DPI screens; it turns
out that, while quite a bit of progress has been made, this problem has not
yet been fully solved.

There are certainly a lot of advantages to high-DPI displays (generally
considered to be those with at least 200 pixels per linear inch).  Text
is rendered in an especially clear and readable fashion.  Photos from
digital cameras can be 
displayed at something resembling their native resolution.  And, for those
of us with sufficiently sharp eyes, high-DPI allows more work to be
crammed onto a screen, increasing productivity.  But, if the desktop
environment and associated applications are not aware that a
high-DPI screen is in use, the result can be unreadable text and
unusable, microscopic screen elements.
High-DPI display support

So how have the Linux desktop environments responded to high-DPI
displays?  There appear to be 
two different basic approaches.  The one used by GNOME and some web
browsers is to hide the display resolution behind pixel scaling; in
essence, the environment lies to applications, then turns each application
pixel into a 2x2 array of screen pixels.  It's a relatively quick solution,
but, as we'll see, it leads to some unfortunate behaviors.

The alternative is to have applications deal with display-independent units
(points, centimeters, inches, whatever) and hide the scaling required.  KDE
appears to have taken this approach.  It seems to work well enough as long
as applications play along, but here, too, the problem is not entirely
solved.

Your editor's experiments have mostly been with GNOME, so this article will
have an unavoidable bias in that direction.  In GNOME, pixel scaling is
managed with the inevitable gsettings registry value; to turn on 2-to-1
scaling, a command like this can be used:
    gsettings set org.gnome.desktop.interface scaling-factor 2


Setting the scaling factor back to one turns off scaling.  Scaling
should be enabled by default if GNOME detects a high-DPI display;
otherwise a command like the above can be used.  This value can also be
adjusted in gnome-tweak-tool.  Should you run into bugs or
weirdness (like only a quarter of the screen being used), setting the
scaling factor to one then back to two will often straighten them out; your
editor has ended up creating a fixscaling script for just this
eventuality.

Firefox implements a similar sort of pixel scaling, but it doesn't seem to
figure out when to use it on its own.  The solution is to go into
about:config and set the layout.css.devPixelsPerPx knob
to a value like two.  Alternatively, one can make things work by
configuring the use of 30-point fonts, but that will make a mess of a lot
of web sites.

In the KDE world, there seem to be a couple of parameters to set if the
desktop doesn't figure things out on its own.  The "application appearance"
dialog has an option to set the dots-per-inch resolution used for
font rendering; setting that to a value close to your screen's pixel density
(or lower; 150 seems to be a recommended value) will make text readable.
The size of icons is also nicely configurable in KDE; its use of SVG icons
helps to make this option work well.  Obviously, one will want to make
icons larger on high-DPI displays.
Difficulties

So it seems that some support for high-DPI displays is in place for
Linux.  But there are still a lot of nagging little details — some perhaps
not so little — that pop up when using a system with such a display.

For example, what happens when one plugs an external monitor (or projector)
into such a system?  That display almost certainly is not also
high-DPI.  The techniques used to make the high-DPI screen
will have the effect of turning the lower-DPI screen into an
extra-low-DPI screen.  In your editor's case, this problem has made
the use of external monitors on the new laptop nearly impossible.  The word
is that this behavior is the results of limitations built deeply into the X
Window System which, after all, was developed when 75dpi was a
high-DPI screen.  Things will be much better under Wayland, we are
told, but there doesn't appear to be a lot of relief in store before then.

Pixel scaling can also cause a lot of confusion with applications that are
not prepared for it.  Here is an old version of gthumb (the version shipped
with Fedora 20) with scaling in effect:

  


With scaling turned off, the result is rather more satisfying:

  



(It should be noted that gthumb 3.14.x handles high-DPI displays in
a much better manner.  Your editor will reserve comment on some of the
other user interface changes made during that time, though.)

Over time your editor has found a few applications that do better with
pixel scaling turned off.  Happily, there is an easy way to do that on a
per-application basis: simply set the GDK_SCALE environment
variable to the desired scaling value.

Another problem with pixel scaling is that it can cause even the
high-DPI screen to appear to have a low pixel density.  As a result,
for example, gnome-terminal believes it's running with 7-point
fonts, something that would normally be illegibly small.  The sizing is
confusing, but it also makes it hard to get that perfect size: seven points
is too large, but a 6-point font, being quite a bit smaller, is illegible.
All of this is somewhat unfortunate, since points are supposed to be
real-world physical dimensions, but that connection has been lost for now.

There is no shortage of web sites that come through badly on
high-DPI displays — including this one in many cases.
User-interface elements can be so small as to be unusable, and images are
reduced down to postage stamps.  Xkcd becomes unreadable in such a
setting.  Turning on pixel scaling in Firefox makes a lot of these problems
go away at the cost of losing a fair amount of screen space to the
expanded icon bars at the top — and to larger advertisements.  The Chromium
browser, surprisingly, appears 
to have no high-DPI awareness at all at the moment; the sad result
is that even Google sites can look terrible there.

In general, any web site that is trying to manage its page layout using
pixel sizes is going to run into trouble on high-DPI displays.
Fixing that problem will take a long time, and involves some interesting
tradeoffs.  The tiny-image problem can be fixed by shipping
higher-resolution images and getting the browser to scale them to the
desired size, but that can increase bandwidth consumption considerably.
The alternative — sensing the screen resolution and shipping appropriately
sized images — is a lot more work to support.
Some closing thoughts

Naturally, the new machine came with Windows preinstalled, so your editor
had the chance to see how that system copes with the high-DPI
display.  The situation there is perhaps a bit better, but Windows has not
fully solved the problem either.  The basic system user interface works
well, but web pages can run into trouble there, and some applications, even
popular, high-profile applications, have not yet made the adjustment.

Making applications work properly in an environment where displays can have
widely varying densities — even on the same system — is not an easy
problem to solve.  The good news is that we are much of the way there; the
bad news is that there is still a lot to be done, and, in some cases, a
change of approach may be needed.  In particular, approaches based on pixel
scaling have all the appearance of being a short-term kludge that gets
things working while a real solution is being worked on.

That real solution, it seems, almost has to involve divorcing applications
from the individual pixels on the screen.  Once applications are working in
pixel-independent units almost all of the time (there may need to be
exceptions for image editing, video playback, etc.), the underlying
environment can work on rendering in a visually similar way on all
possible screens.

Until then, it is good to see that developers are working on making
high-DPI screens work better with Linux.  A fast rate of progress is
arguably not surprising; after all, desktop developers hardly seem like a
crowd that would be resistant to the allure of a beautiful new screen.  So
we can probably count on those developers to fix up the remaining problems
in relatively short order.
            