How does display scaling work on macOS?

Question

So, I have a MacBook Pro 15” and I recently bought an LG 27” 4K monitor.

When I connected the monitor, system report said that the original resolution is 4K but the picture looks like 1920x1080 (using 4 pixels for 1 displayed pixel) on the screen. The text was too big for me.

I was then able to access scaling options and opted for the option that looks like 1440p with the original resolution of 5k. This seems to give the best image and size for this external monitor.

Now, I want to understand why the image is clear at what looks like 2560 x 1440 on my 4K monitor since the pixel distribution is not a modulus of 0. In my understanding, there is no way to distribute a 5k picture on a 4K monitor and yet get a clear picture. Since 5k is only 1.33 times bigger than 4k horizontally and vertically, how does it render? Is the picture quality worse than I think?

Answer 1

When you choose 'looks like 2560x1440' and that is not an integer scale factor of 4K (3840x2160), macOS creates a virtual display twice the size (i.e. 5120x2880). All software (OS and applications) writes to that double size display.

The display driver then downsizes from the 5120x2880 virtual display to the 3840x2160 physical display. This ensures consistent optimisation which applies across all applications.

As you know, this creates a slight fuzziness but does mean that text looks the intended 'right' size.

When choose 1920x1080 the scaling factor to 3840x2160 is exactly 2 so that the virtual display (twice 1920x1080) is the same size as the physical display. As a consequence, no fuzziness, but everything looks far too large.

Macs always look best (text size and crispness) with screens that have about 220 pixels per inch (ppi). Older screens were all about 110 ppi. Anything else there is a compromise between best crispness and best text size. It is not chance that the new 24" (actually 23.5") iMac has a 4.5K screen - 4480x2520 and 218ppi.

Marc Edwards at Bjango has an excellent write up illustrating the compromises which must be accepted when a display is not about 220ppi. Thanks to @Wollmich for pointing me to this article.

Answer 2

What happens is that the system essentially renders the image offscreen at a much higher resolution where you haven't got "a third of pixel" and similar. Then that image is downsampled to the actual resolution of your monitor and displayed.

This process is ofcourse not "lossless" and will give a slightly worse image than if you had a monitor of a higher resolution where this problem does not occur. However, due to the relatively high resolutions we're working with today, it doesn't look as bad as you might think.

It is always a tradeoff of whether you prefer the perfect quality of having 4k and 1920x1080 match each other perfectly, or you rather have more screen real estate by opting for 4k and 1440p.

Answer 3

Great question. The best explanation I've found of how the end-to-end display pipeline works on mac is this comment, which I will summarize and expand upon below.

Basically, there are 4 components at play: we have "logical pixels", which is the coordinate system as seen by apps (for instance, if you use cmd+shift+4 screen capture, the width/height dimensions given are in units of "logical pixels"). Next you have the backing pixel store. The relationship between "logical pixels" and the backing pixel store is given by the backingScaleFactor property of an NSWindow. OSX composites the backing stores of all windows together into a final "virtual" framebuffer. Next we have the actual "frame buffer" which represents the actual signal that would get sent to the monitor (the virtual and actual frame buffer need not be the same, as we will see shortly). Finally we have the monitor itself, which has a "native pixel resolution": if the signal sent to the monitor differs from the native pixel resolution, the monitor must perform upscaling/downscaling (or if it's a fancy monitor it might support 1:1 mode where it displays the image with borders, without applying upscaling).

So all this raises the question: how exactly does the resolution you set in system preferences ultimately get mapped to the signal that is sent? The short answer is that the resolution you set there is the "logical" resolution, and hidpi (or non-dpi) controls the backingScaleFactor (and accordingly whether 2x assets are used or not). But there's an additional catch: when you use the hiDPI modes, if the virtual framebuffer resolution does not match the native display resolution, macOS will downscale/upscale as needed so that the output signal is always at the native resolution. (If on the other hand you use a non-hiDPI mode, then you have logical resolution = framebuffer resolution = output signal resolution, so it's the display itself that does any upscaling).

Let's consider some concrete scenarios: we have a QHD monitor (2560x1440 native resolution). Within system preferences we select a non hi-dpi resolution of 2560x1440. Then the logical resolution = frame buffer resolution = signal sent to display = 2560x1440. If we instead selected a 1920x1080 resolution, then the three are all equal to 1920x1080, and this is e.g. reflected in the monitor's OSD.

Now within system preferences, say we select a resolution of 1920x1080 (hidpi). When you choose a "hidpi" display mode, this means that the backing store of each window and composited frame buffer is at 2x the logical resolution. You can see this in system profiler: it states "resolution 3840x2160" but "ui looks like: 1920x1080". In this hidpi mode, AppKit automatically selects the @2x version of sprites, thus scaling things such that even though the backing store is twice the resolution, the size of things is also now doubled making things "logically" appear as 1920x1080.

But we don't have a 3840x2160 screen, we only have a 2560x1440 screen. macOS now resamples/downscales the virtual framebuffer to 1440p before sending it to the display. This rescaling is where blurriness is introduced: because it is a non-integral multiple, we get the messy artifacting as described by other posts like this or this. Moreover, no matter what hidpi resolution you select, the signal sent ultimately always matches the native resolution of the monitor.

---

The benefit of this display-scaling approach is that apps don't have to account for arbitrary scale factors: as long as they work with 1x and 2x, the scaling to other resolutions is handled transparently and system wide. The downside is that besides the blurriness, it means that an application actually has no easy way of identifying what the end-resolution the user physically sees is (which is partly the point, the application should not care about it). Consider the case of a image-viewer: the input image might be 1080p, but if we have hiDPI mode enabled backingScaleFactor = 2 then the system will actually give us a 2160p frame buffer to render into, for which we'll need to do upscaling ourselves (pretend we're using raw OpenGL or something to avoid any Cocoa layers). But that's not the end of the story, the system may transparently rescale the frame buffer to the native display resolution. In fact if enabled 1080p-hiDPI mode on a 1080p display, the system would downscale the framebuffer back to 1080p, so the resolution as seen by the viewer would only be 1080p.

Answer 4

As far as the quality is concerned: If you have a 4K monitor with 3840 by 2160 pixels next to a 5k monitor with 5120 x 2880 pixels, the cheaper 4K monitor can obviously not have the same quality as the 5k monitor, but then it is also an awful lot cheaper.

I can’t say anything about cheap monitors where being cheap might make the picture quality even worse, but I bought two 4.5K monitors each for less than a third of a 5k monitor. Setting both to 2,560 width, characters have exactly the same size. I have to look very, very close to see that the picture quality is not quite the same. I’d rate it 90% vs 100%. If you didn’t know that one monitor should have less quality, you might never notice. And the picture quality is absolutely fine when you work with it, and it is visibly a lot better than a 27” monitor with 2,560 x 1,440 native pixels.

A 32 inch monitor is harder to compare. If you use 32” because your eyesight is bad and you want bigger text, then the picture quality is the same, almost the same as the 5k monitor. Because the pixels are 20% bigger someone with better eyesight might notice the pixels, but you wouldn’t.

If you bought 32 inch to show more text at same size and set the resolution to 3072 x 1728 pixels, then your loss in quality would be much worse. You wouldn’t want 32” 5k, but nobody sells that. You can get 32” 6k but they are really expensive.

Finally, if you use 1920 x 1280 resolution for larger text, then your 4K monitor now uses optimal 2:1 scaling. Text is bigger but perfectly scaled. The 5120 x 2880 5k monitor is not optimally scaled, but the resolution Is so high you cannot see a difference. But the extra money you paid for 5k was wasted.