Retina rendering
Drawing Linux windows at your Mac's real pixel density, so they look as sharp as Mac apps.
On this page 4 sections
Off by default. Linux windows are normally drawn one X pixel per point — and on a Retina screen a point is four physical pixels, so every X pixel is stretched across all four. That is why Linux text can look softer than the Mac's own. With this on, each X pixel is one physical pixel instead, and Linux apps draw at the detail your screen actually has.
What changes#
| Off | On | |
|---|---|---|
| Each X pixel covers | 1 point — 4 physical pixels | 1 physical pixel |
| MSL tells Linux the screen is | 96 dpi | 192 dpi |
| Pixels an app draws | — | four times as many |
Windows stay the same physical size. The screen MSL reports grows by exactly as much as each pixel shrinks, so an app lays out for the same amount of glass — it simply has four times the pixels to say it with.
What it costs#
Four times the pixels, and every one of them crosses the connection between Linux and your Mac. Expect it to cost speed, most obviously on large windows and on anything drawing in software rather than on the GPU. That is the whole reason it is off by default rather than simply on.
With Native scaling#
They answer the same question, so Retina rendering wins when both are on. Native scaling makes Linux windows smaller at the detail they already had; this keeps them the size they are and gives them more detail.
If some apps change and others do not#
Toolkits disagree about where to read the display's density from. MSL publishes it both ways — as the screen's physical size, and as the Xft.dpi resource that Qt, Tk and xterm read — but an app that hardcodes 96 will ignore both and keep its old size. Nothing breaks; it just will not have grown sharper with the rest.
Applies to apps opened after turning it on. One already on screen keeps the density it started with.