LWN: Comments on "High-DPI displays and Linux"

"native resolution" of photos from digital cameras ?

sethml — Tue, 19 May 2015 20:36:14 +0000

My 5K retina iMac shows 14.7MP. My Nikon D300 shoots 12.3MP. It's pretty cool seeing *all* the pixels at once. My more modern Nikon D750 shots 24.3MP, so I don't get to see all of them, but seeing more than half is still pretty awesome.

The world really needs >4K display support better standardized/supported so you don't have to buy Apple's hardware to get it...

"native resolution" of photos from digital cameras ?

rleigh — Tue, 23 Dec 2014 21:11:53 +0000

This is, strictly speaking, not correct. Like many terms (SI unit prefixes...), resolution is used largely incorrectly in the domain of computing and without understanding of what it really means. It's a term which has been taken and used out of context. Resolution is a physical measure of the smallest object an imaging system can *resolve*. If two small objects next to each other are not distinguishable as separate objects (they are one blob), then the system has not *resolved* them. In the case of microscopy and cameras, the resolution (resolving power) is defined by the optics of the system (lens numerical aperture, plus any further diffraction and aberation). This is *independent* of the detector (CCD/PMT/film), but the detector will have to sample at least at twice the bandwidth to satisfy Nyquist-Shannon sampling criterea, so for a correctly set up system your detector will be sampling at twice the optical resolution in x and y. [For cheap cameras with massive CCD sizes, the optics are so poor you end up sampling pointlessly at many times the Nyquist limit; turn on 2x2 or higher binning to get smaller, less noisy and higher quality images. Compare with an SLR with better optics and a smaller [pixel] size but higher quality CCD!]

http://en.wikipedia.org/wiki/Angular_resolution
http://www.svi.nl/NyquistRate

Resolution is not, and never has been, a *size* measure as used by CCDs and monitors. I know it's common practice in computing, but it's wrong nonetheless. You can measure the well/dot pitch (i.e. distance between pixels), which would be better, but strictly speaking that's not really a measure of resolution either (in this context) since it's a property of an optical system and not of the detector/emitter of a light signal such as a CCD or monitor.

Regards,
Roger

"native resolution" of photos from digital cameras ?

dlang — Tue, 23 Dec 2014 19:29:01 +0000

given that the most pixels you can get on a screen is ~8MP (for a 4k screen), you still aren't going to be showing your digital pictures at 1-1 zoom for most modern cameras

"native resolution" of photos from digital cameras ?

bfields — Tue, 23 Dec 2014 19:16:23 +0000

"Resolution, by definition, measures pixels or dots by a unit of distance."

It's also commonly used for total size in pixels. (E.g., "the resolution of my laptop's monitor is 1280x800").

So "native resolution" here means "full size in pixels".

Rail against loose use of language if you want, but I think that sort of usage is too common to exclude it as a definition of "resolution". And in this case there's no ambiguity (since as you point out a digital photo has no inherent physical dimensions).

"native resolution" of photos from digital cameras ?

lmartelli — Mon, 22 Dec 2014 20:48:03 +0000

"Photos from digital cameras can be displayed at something resembling their native resolution"

Pardon me, but what is the "native resolution" of photos from digital cameras supposed to be ? Resolution, by definition, measures pixels or dots by a unit of distance. But photos from a digital camera have to physical dimensions, so they can't have a native resolution. Unless you are thinking of the resolution of the sensor, but since they are usually less than a centimeters, their resolution is much higher than even the highest-dpi display that I know of.

Opera for Linux has HiDPI support on Linux

Velmont — Wed, 17 Dec 2014 19:19:13 +0000

Oh, that's embarrasing. It's been so long since I commented on LWN that I managed to reply to a comment instead of the article as I thought I was doing. *shrug*.

Opera for Linux has HiDPI support on Linux

Velmont — Wed, 17 Dec 2014 19:15:37 +0000

Since I saw you mention Firefox and Chromium, I thought it'd be good to mention that Chromium-engine based Opera has HiDPI support on Linux.

Opera for Linux just came out as stable (not only beta and developer stream): http://opera.com/

[I work at Opera]

High-DPI displays and Linux

josh — Fri, 21 Nov 2014 17:57:11 +0000

While it isn't overly convenient, you can actually press Insert on the X1 Carbon keyboard: Fn+I. You can also press Fn+S for SysRq, and Fn+T for Print Screen. (Documented in the user manual, along with several more.)

Personally, though, I only have one application that actually uses the Insert key: GCCG.

High-DPI displays and Linux

hamasaki — Fri, 21 Nov 2014 17:38:21 +0000

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

It's really not. The only challenge is agreeing on a system, which unfortunately is perhaps the area the free software community has the most trouble with.

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

Desktop developers are also the type who often stick to one system, and apparently we have at least 4 different approaches to solving this problem so far. The easy fixes have already been done. I'm not optimistic that the situation is going to significantly improve any time soon. It's not like the KDE developers are going to wake up and switch to Gnome's scheme when they have some free time next week. This isn't a technical problem that can be solved by a couple hours of debugging.

Apple has solved this problem because they can just declare the entire system by fiat. Microsoft is close behind, because they control most of the software and a little of the hardware. Free software does great when there's a BDFL like Linus, Guido, Matz, or Larry, but the desktop GUI has no such person. The closest we have is Ubuntu, and they're the only ones I think have any shot at fixing this in the next 5-10 years -- and they've chosen a 5th option, "Invent a new display server which is neither X11 or Wayland".

Oversampling, or scaling down

epa — Fri, 21 Nov 2014 11:26:40 +0000

An HTML document is not a computer program and does not contain code for scaling glyphs or icons to a particular size. Firefox is, and contains well-written code for those tasks. You may as well say that plenty of legacy Microsoft Word documents can be scaled by fractional values when viewed in Microsoft Word.

Grab a PC running Windows 7 box and set it to 150% font scaling, then try a random assortment of third party software written before 2010. You will see the mess I am talking about - and I assume the situation with older Mac OS X programs is the same.

It is great that Firefox scales well and I quite agree it proves that scaling by an arbitrary factor is *not difficult*. That has very little bearing on whether existing programs, which exist in binary only form and cannot be modified, implement non-integer scaling reasonably. Even if 90% do so, ten per cent do not.

Oversampling, or scaling down

dlang — Thu, 20 Nov 2014 22:16:43 +0000

HTML is designed to be resolution independent

A lot of web designers have been working hard ever since to undermine this design, but they have had limited success

Oversampling, or scaling down

quotemstr — Thu, 20 Nov 2014 21:48:07 +0000

Firefox manages to render plenty of legacy websites that were not designed to be resolution-independent and scale them by fractional values. *That's* the point.

Oversampling, or scaling down

epa — Wed, 19 Nov 2014 09:28:55 +0000

I think the point is that there's an existence proof of many legacy programs from the 2000s and 1990s which produce a nasty-looking mess when asked to scale by 3/2 (let alone, say, 4/3). That does not negate the existence of a large body of carefully written programs (of which Firefox is one) which handle arbitrary scaling perfectly. But it is (I presume) the reason why Apple chose to scale by an integer factor and then resize in the GPU if necessary. I quite agree, if starting from scratch then arbitrary dpi need to be supported.

On Linux, the legacy programs may often be ones using X11 server-side fonts. Currently X ships with 75dpi and 100dpi bitmap fonts. If it included 150dpi and 200dpi sets, programs like xterm could use those and so scale up nicely.

High-DPI displays and Linux

daniels — Tue, 18 Nov 2014 09:08:24 +0000

Presumably not with any GTK+ apps, as it only supports integer factors.

Anyway, like I said, application awareness can give you arbitrary factors anyway, as the whole point of the interface is to be able to opt out of scaling. At which point you have a full-size buffer.

Oversampling, or scaling down

quotemstr — Tue, 18 Nov 2014 05:32:24 +0000

Thank you. It's frustrating how some people say that "$X is impossible!", and then when confronted with an existence proof of $X, just reiterate the claim that "$X is impossible!".

Fractional scaling in practice works fine; thanks for implementing it in Firefox. I hope the Wayland people come around: for some hardware (like mine), fractional scaling is precisely the right thing. Not everyone owns a Macbook.

If the Wayland developers persist in supporting only integer scaling factors, I suspect desktop environments will just hardcode 1x scaling and make toolkits do fractional scaling, which will be a mess all around.

High-DPI displays and Linux

quotemstr — Tue, 18 Nov 2014 05:19:00 +0000

> No, only integer factors which apply equally to both horizontal and vertical scaling.

Sorry, but that decision makes Wayland useless for me. Then again, I'll probably end up using Mir instead; I hope Mir's authors are more cognizant of actual user needs.

On my laptop, a Lenovo Carbon X1 2014 model, 1x is too small and 2x is too big. A scaling factor of 1.5 is perfect.

I read the mailing list thread. The argument about imprecise scaled graphics is bogus: Firefox manages to scale by non-integer factors *just fine*.

High-DPI displays and Linux

josh — Tue, 18 Nov 2014 00:19:17 +0000

Sorry, misread your comment. :)

High-DPI displays and Linux

javispedro — Tue, 18 Nov 2014 00:09:02 +0000

Ah yes, I meant it works with Gtk+2 programs too.

High-DPI displays and Linux

bernat — Mon, 17 Nov 2014 09:25:16 +0000

I am also doing that. Most applications render correctly when Xft.dpi is set to a sensible value (Chromium being an exception). This can be done either with the old way (echo Xft.dpi: 144 | xrdb -merge) or with the new way, through XSETTINGS.

The old way works without any additional daemon but is not dynamic. The application will read the settings from xrdb at start (or sometimes when told to create a new window, like this is done for Emacs).

The new way allows application to be notified when a change happens. It requires a XSETTINGS-compatible daemon, like xsettingsd (or gnome-preference-daemon). The correct DPI setting should be multiplied by 1024. XSETTINGS can also be per screen (with xsettingsd, this requires to run two instances).

I am using xrandr to set DPI settings correctly and propagate the result to xsettingsd with this ugly little script:
https://github.com/vincentbernat/awesome-configuration/bl...

Except Chromium, everything scales automatically: Emacs (GTK version, otherwise, not dynamic), GTK2 and GTK3 apps, libvte-based terminals, QT apps.

For Chromium, I just set to zoom settings to 150%. Work is in progress in Chromium to fix that correctly. Currently, there is a flag to compile HiDPI support but DPI is computed from the screen size instead of using the DPI set through XSETTINGS like other apps. Usually, this makes Chromium interface too big. And many widgets are broken. This is known and currently being fixed.

High-DPI displays and Linux

bronson — Sun, 16 Nov 2014 12:35:35 +0000

Not necessarily... Turn off "Displays have separate spaces" in the Mission Control preferences to have the traditional window-everywhere behavior.

High-DPI displays and Linux

josh — Sat, 15 Nov 2014 20:15:41 +0000

> In fact, the above font DPI-only trick also works with Gtk+2 programs.

Works fine here with GTK+ 3 programs.

Oversampling, or scaling down

javispedro — Sat, 15 Nov 2014 20:11:38 +0000

But no one uses X11 subwindows any longer, or so we heard from Wayland developers! </ironic>

On a more serious matter: With Wayland, Gtk+ becomes the owner of the surface, and thus the problem of how you actually render all of your non-integer cordinate widgets becomes Gtk's problem (or OpenGL's).

So this excuse no longer works in a Wayland scenario. Qt has non-integer scaling ratios and they work quite OK.

High-DPI displays and Linux

javispedro — Sat, 15 Nov 2014 20:04:52 +0000

I agree. It's absurd that Gtk+3/Gnome3 has decided on integer scaling ratios. Certainly OS X influence...

In fact, the above font DPI-only trick also works with Gtk+2 programs. The icons look smaller though. It looks much more reasonable in my Surface Pro than Gnome's/OSX idea of scaling everything to 2x and then back to 1.5x, which makes text look very fuzzy.

High-DPI displays and Linux

javispedro — Sat, 15 Nov 2014 20:01:42 +0000

The same as Windows, except that OS X will refuse to render a window that is half-way between two monitors (unless it's currently being moved, in which case it just uses raster scaling). It will hide the window in every monitor except the one where most of its area is.

High-DPI displays and Linux

javispedro — Sat, 15 Nov 2014 19:57:22 +0000

Windows does fractional scaling. To be honest it has the best scaling approach of every current OS implementation, as long as you ignore the baggage of Win32 applications....

Oversampling, or scaling down

jospoortvliet — Sat, 15 Nov 2014 18:03:31 +0000

Xrandr works, but I believe GNOME ignores dpi settings. KDE apps obey it so you get a message if you use both. But you can configure dpi for KDE apps, not sure about GNOME.

High-DPI displays and Linux

lsl — Sat, 15 Nov 2014 16:25:47 +0000

It could. I don't think the Linux kernel implementation of 9P (v9fs) really supports it, though.

On can certainly build nice things on top of 9P auth. See this paper on what is done on Plan 9:
http://plan9.bell-labs.com/sys/doc/auth.pdf

Think kerberized Unix services, but a thousand times simpler and actually unified on the system level.

High-DPI displays and Linux

roc — Fri, 14 Nov 2014 10:06:42 +0000

Macs window coordinates use a DPI-independent unit so windows don't change size as you move across screens with different DPI. The backing store for a window is resized when the majority of the window moves to a different screen.

Oversampling, or scaling down

roc — Fri, 14 Nov 2014 10:04:21 +0000

I mean Firefox scales arbitrary Web pages by fractional scales and they almost always look fine. Those Web pages use complex layouts and generally were not tested over a range of scale factors.

High-DPI displays and Linux

jreznik — Fri, 14 Nov 2014 09:20:40 +0000

I've got X1 Carbon this week from my colleague who was very unhappy about it. HiDPI, ESC placement, missing insert. I don't mind ESC but insert... On the other hand I replaced my old T520 with X1 as my use case changed a lot. From T520 being powerful workstation for developer to meeting laptop. I ordered OneLink dock, so when docked, I'll be using keyboard (and thus ESC and instert) and for meetings, I don't mind too much. Etherpad is my only friend there :).

So far I got best results with Plasma 5, still, it needs quite a lot of tweaking and not everything there is dpi-independent. GNOME approach with scaling by factor of 2 is no-go. It would work for high resolution displays, X1's resolution is not that high and gives you very small screen with everything being so huge. Single head for a lot of apps is solvable. Somehow. Not perfect but it works.

The bigger issue is connecting second LCD, non HiDPI. In the end, I was able to find compromise font DPI settings that makes it somehow usable on both displays simultaneously but... On Carbon, it's a bit too small, on external LCD it's a bit too big. I can live with it, now. Xrandr scaling is unusable - too blurry. Firefox can be solved by https://addons.mozilla.org/en-US/firefox/addon/autohidpi/

High-DPI displays and Linux

giggls — Fri, 14 Nov 2014 09:11:35 +0000

Up till now, I have been using 9p for sharing drives on kvm hosts only.

Will 9p provide a decent solution for centralized home directories without the security nightmare of NFS3?

Oversampling, or scaling down

ploxiln — Fri, 14 Nov 2014 06:44:53 +0000

On OS X, Hi-DPI capable applications render at twice the quality when rendering 2x (in each dimension of course). They're not really "resolution independent", they don't support arbitrary dpi, they just do 1x or 2x. Virtually all applications now at least support 2x text through OS X's CoreText or whatever, and most render fully at 2x quality.

So when they're scaled from 2x to 1.5x, they have extra detail in the 2x pixels, which is then combined/sampled for a much smoother 1.5x scale from the "reference pixel size".

It's a pretty clever way to get more applications to more easily support reasonably Hi-DPI display, IMHO. Just support 2x, and with all that detail the OS can scale that a bit and still have it look good.

High-DPI displays and Linux

lsl — Fri, 14 Nov 2014 01:53:36 +0000

> Plan 9 was based on 2.9BSD, rather than SVR4.

What? Plan 9 isn't based on any version of Unix. Some of its user space programs originated in late Research Unix, like the shell, rc(1), and the build tool mk(1). So did some other ideas, most likely.

I don't think there's a base for any statement such as the above, though. Where did you get this from?

High-DPI displays and Linux

roskegg — Thu, 13 Nov 2014 22:21:44 +0000

9P2000 supersedes NFS.

High-DPI displays and Linux

alexl — Thu, 13 Nov 2014 19:28:02 +0000

Nobody wants to specify actual measurements in their apps in units like "dots per degree", so instead what you use is something of the same kind of measure, but with a different scale. Its called a "reference pixel":

http://www.w3.org/TR/css3-values/#reference-pixel

The reference pixel is the visual angle of one pixel on a device with a
pixel density of 96dpi and a distance from the reader of an arm's length.
For a nominal arm's length of 28 inches, the visual angle is therefore
about 0.0213 degrees. For reading at arm's length, 1px thus corresponds to
about 0.26 mm (1/96 inch).

This is essentially what gnome uses. Following the recommendation above that link:

For lower-resolution devices, and devices with unusual viewing distances,
it is recommended instead that the anchor unit be the pixel unit. For
such devices it is recommended that the pixel unit refer to the whole
number of device pixels that best approximates the reference pixel.

High-DPI displays and Linux

zev — Thu, 13 Nov 2014 18:13:29 +0000

Yes, dots-per-degree does seem like the more relevant unit -- though this also has the complication that most of the display devices we deal with are flat, not spheres centered on the viewer, so the number of field-of-view degrees per display-surface inch is different at the center of the display than at the edges. (Though I guess in hypothetical practice it probably wouldn't be enough difference to matter much, at least in "normal" cases.)

High-DPI displays and Linux

josh — Thu, 13 Nov 2014 17:17:46 +0000

100% of what I run respects that setting, other than Firefox, which has its own setting.

xterm does not, but I don't run xterm. If you want apps like xterm to automatically scale, you'd have to set the X server DPI.

Oversampling, or scaling down

xbobx — Thu, 13 Nov 2014 16:20:33 +0000

> tk doesn't suppor HiDPI at all

I think Tk will correctly honor the DPI by default, but ignore DPI if a font size is a negative value. I know this because years ago after a distro update tkdiff started to render at different sizes on my different-DPI monitors, rather than scaling to approximately the same size. I tracked it down to a "bugfix" where somebody changed the default font size to a negative size in order to work around situations where the DPI was set incorrectly (sigh).

Oversampling, or scaling down

zyga — Thu, 13 Nov 2014 15:41:52 +0000

No, because you scale up by x2 and there are no fractional parts to worry about so you get good picture. Then you scale the entire full-screen buffer by 0.75 to get another picture.

This is distinctively different from scaling individual drawing operations by 1.5

High-DPI displays and Linux

giggls — Thu, 13 Nov 2014 14:22:43 +0000

Whats your Problem with NFS?

NFS4 is a decent remote filesystem, not "No File Security" anymore.

The only thing I would like to have in Linux Implementation would be a Shared Key Setup for environments with a couple of hosts, where a full-fedged Kerberos setup would be overkill.

Sven