Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Default vs Scaled resolution performance
- Thread starter mszilard
- Start date
- Sort by reaction score
Technically: yes
Practically: no
Just chose the size that looks best for your eyes. Your M1 MBP is able to run one external 6K display with 6016 by 3384 resolution at 60 Hz additionally to whatever the internal display is showing. So don't think for a minute, you're able to feel a performance impact of the internal display setting.
That's because everything is smaller and drawn with fewer pixels. More GPU power won't help with that problem. Only even higher pixel density (@3x Super Retina) can make very small text scroll smooth. Instead of 2560×1600 (Retina) you would need a 3840×2400 (Super Retina) display. For now this technology only exists for phone-size screens. The iPhone Pro with a 460ppi display scrolls tiny text smooth despite not having an M1 chip.
Are we sure that scrolling on a @2x or @3x display is smoother because the scrolling increment is a "small" pixel and not a "large"/layout pixel? It's safe to say that the initial and final positions must be layout-pixel aligned. Of course that doesn't prevent scrolling from being smoother by using the smaller pixels. It's just that I can't remember reading anything either way on this subject.
You rightfully point out RAM bandwidth as an issue. An 8K image is 7680*4320*4 bytes which is around 125MB.
Reading that at 1000Hz from RAM would require 125GB/sec of bandwidth, which is not much less than double what the M1 has and more than half of what an M1 Pro has.
If we go down to 60Hz then we arrive around 8GB/sec, however we also need to write the scaled version back to RAM to be available for the display data fetch.
For a more realistic example let's consider "looks like" 2560x1440 on a 4K display. Scaling one frame buffer reads 5120x2880x4 bytes and writes 3840x2160x4 bytes. Doing that 60 times per second consumes 5GB/sec of RAM bandwidth with about a 2:1 ratio of reads to writes.
If we add that rendering nearly double the amount of pixels also requires more bandwidth compared to native resolution I believe it is safe to say that in this situation there is an overhead of around 10% of the total memory bandwidth of an M1.
Yeah, that's not exactly what's happening. In 2:1 mode (so, "looks like 1280x800" on a 2560x1600 MBA), modern/"retina aware" software that understands "HiDPI" resolution & comes with high-resolution icons/bitmaps can use the full 2560x1600 resolution. What's changed is the "pixels per inch" value that the OS converts 'logical' coordinates, font sizes etc. in points, mm etc. into physical pixels. This also doubles the "UI size" - i.e. the pixel size of system fonts, menus, icons, dialogue boxes etc.
The simplistic "2:1 pixel scaling" bit comes into play with older software that doesn't support HiDPI and assumes regular resolution. If you run some old applications on a retina screen you'll notice that parts of them look fuzzy.
"2:1" scaling really isn't the problem and doesn't have performance issues (aside from the fact that you're running at a pretty high resolution c.f. a non-retina display) - the issue (although often over-blown) is with the other "non-integer scaled" modes that do something a bit more complex in order to provide a choice of UI sizes.
I wrote a long spiel on this a couple of months ago: https://forums.macrumors.com/threads/psa-4k-display-resolutions.2345906/ - that's referring to 4k vs. 5k desktop displays, but the principles are the same, but with the wrinkle that some MacBook models actually default to non-integer modes.
Thank you very much for explaining. I understand. I discussed this with Apple in 1990 when my company developed a very high resolution monitor, but it took a while to happen.
Scaled resolutions always have a performance hit.
The best balance between image quality and performance is using 2x, (i.e. if physical pixels are 4000x2000, then 2000x1000 HiDpi would be optimal)
but even the optimal resolution would have a performance penalty compare VS the real physical resolution. Performance at scaled 2000x1000 Hidpi is worse than native 4000x2000 (beyond UI render size)
Using vector drawing apps as Animate, Illustrator or Harmony is where you can see this best.
I'm working switching from retina to native pixel resolutions with the rMBP, MP13 and Mac Studio Max, even with the latest, with complicated projects I need to force the apps to open in low res. UI is blurry but apps performance is unparallel. Using native is like removing the Battle Armor to a Saiyan.
But for regular use, with the latest macs it shouldnt be noticeable beyond intensive task.
I would love to open UI apps in Hi res but the working/creation area in low res or have a switch when needed.
The best balance between image quality and performance is using 2x, (i.e. if physical pixels are 4000x2000, then 2000x1000 HiDpi would be optimal)
but even the optimal resolution would have a performance penalty compare VS the real physical resolution. Performance at scaled 2000x1000 Hidpi is worse than native 4000x2000 (beyond UI render size)
Using vector drawing apps as Animate, Illustrator or Harmony is where you can see this best.
I'm working switching from retina to native pixel resolutions with the rMBP, MP13 and Mac Studio Max, even with the latest, with complicated projects I need to force the apps to open in low res. UI is blurry but apps performance is unparallel. Using native is like removing the Battle Armor to a Saiyan.
But for regular use, with the latest macs it shouldnt be noticeable beyond intensive task.
I would love to open UI apps in Hi res but the working/creation area in low res or have a switch when needed.
Last edited:
The answer is no! There are special areas on the M-chips called Display Engines, one for every monitor you can connect to your Mac. So the scaling to resolution is neither lowering your CPU nor GPU performance, even battery life should be about the same.
Are you implying that the display engine is doing the scaling? Do you have a source for that?
I don't have a source, but I assume. Scaling is a continuous uniform task, it makes sense to hardware accelerate it and not just run it on the GPU. What would the Display Engine do, if not scaling and syncing the image? Look at the size of these Display Engines, they are about as big as two GPU cores!
I agree with @JinxVi
Apple's display controllers are extremely optimised, they even take a big hit in precious die area just to achieve a small reduction in power consumption. I think it would be very strange if they went through all this effort but would still let the GPU burn energy rescaling images and sending frame buffer data back and forth. A dedicated scaler is compact and extremely power efficient.
I'm sure Asahi folks will know, maybe it would be worth it asking them.
@JinxVi @leman I suppose it would make sense. I just haven't ever seen this mentioned anywhere, including all the Asahi Linux docs and stuff. I might have missed it, they might have missed it, or it simply isn't there ;-) I'd like to see confirmation either way but can't be bothered to hunt this down right now.
To scale they'd have to buffer, what, two lines? That would require 64KB, which is definitely possible.
thats true to some extend, the CPU takes a lot work to do also. Vector graphics apps uses cpu to render drawings so CPU needs 2x,3x, 4x.... to achieve same performance that in native resolution.
As vector graphics are far from having all the performance they need, complex projects or even no so complex takes huge advantage of using native resolution
In Intel retina days, CPU needed to decode 2x JPGs from the webs and so many things before passing it to the GPU, so CPU was a huge impact on retina displays. I dont know if this scenario still being “something” in Apple Silicon with the shared RAM, but CPU for sure is working in order to bring some things out at double or even higher resolution.
But vector graphics are for sure a real proof of performance penalty in retina displays even in a Mac Studio max.
I mean, you can theorize about internals all what you want but having 60fps in native resolution vs 35 in retina is empiric and real world test. I get same fps in MP13 2,5k native display (non retina) than in a MS MAx 4K display @retina 2,5K, so scaling beyond 2x also makes an impact even worse than scaling the ideal 2x.
The UI is loaded at the Display Engines, right, but there are a lot of things happening in the screen beyond the UI when working with computers.
Last edited:
It’s not (just) about power efficiency. By outsourcing system tasks to special engines, the CPU/GPU cores are freed for user applications.
The Security Enclave for example is constantly encrypting and decrypting all data written to disk. The first implementation of disk encryption with FileVault 2 in Lion was indeed a burden on CPU performance and therefore disabled by default.
The Neural Engine is outsourcing all the face recognition and user preference prediction tasks, which used to make iPhoto so slow.
And the Image Signal Processor and Media Engine are assuming all high-resolution video tasks, which would grind any old Mac to a halt.
It’s a recurring theme that the best way to improve performance on Apple Silicon is to directly implement the most demanding tasks in hardware. For every macOS feature there’s a dedicated area in the M-chip to run it.
you can find more about the performance penalty between native scaling and display scaling here, there isn't though, a comparison vs native resolution:
appleinsider.com
What is Display Scaling on Mac, and why you (probably) shouldn't worry about it | AppleInsider
Display scaling makes the size of your Mac's interface more comfortable on non-Retina monitors but incurs some visual and performance penalties. We explain these effects and how much they matter.
appleinsider.com
It depends on how the scaler is designed. Video scalers usually buffer two or three frames, depending on whether they are de-interlacing and/or frame rate converting, and how. But that’s usually done with offscreen video buffers which get transferred to the final video buffer, and the graphics (non-video) scaling, as you say, is usually only one or two lines and it imparts essentially zero latency.