High-DPI displays and Linux

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.