Hacker News new | ask | show | jobs
by vetinari 882 days ago
> This is not that visible but it does produce some blur

At these pixel sizes (except 125%), it is irrelevant. MacOS and iPhone do exactly the same for years, and nobody was ever bothered.

> along with the performance overhead.

By the increased resolution of the framebuffer; the scaling itself is done by hardware (and here I do not mean GPU; I mean output encoder).

1 comments

125% and 150% are really common for available laptops though. The former for the 1920x1200 13-14 inch laptops, the latter for 2560x1600 15-16 inch laptops. iOS doesn't do fractionally scaling, only 2x, and Macs are all designed to run at 200%, though you can set it to 175% or 150%. MacOS looks equally terrible at 125% or 100% (this is due to the lack of subpixel rendering, but I digress)
> iOS doesn't do fractionally scaling, only 2x,

Oh, it does. The framebuffer is integer scaled, but the physical display has different (lower) resolution. As I wrote above, this mismatch is handled by the output encoder.

> Macs are all designed to run at 200%, though you can set it to 175% or 150%.

Macs since around 2016 ship with ~175% default.

Again, the framebuffer is integer scaled (make a screenshot and see for yourself), and then fit to the display with lower resolution.

They do not support 150% or 175% though; these numbers are never shown in UI, just some description like "more space". This is not just Apple-esque hiding of everything that might sound technical; they really do not support 150% or 175%. In reality, it is more like 177,78% or 152,38%; they get something out of it, but that is a different topic.

It is exactly the same approach that Gnome / Mutter uses for fractional scaling. Except that Mutter did the mistake with exact scales.

Oh, iPhones do fractional scaling now, and have for years. The display has gotten much more pixel dense. It is not reported to the developer or the user what the real resolution is.