This might be a dumb question: Is the author looking to run 4k display at HiDPI 8k framebuffer and then downscale? What's the advantage of doing so versus direct 4k low-DPI? Some sort of "free" antialiasing?

▲

mono442 2 days ago | parent | next [-]

That's exactly what he is trying to do. It's really just because MacOS has bad text rendering when graphics aren't rendered at 2x scale.

▲

LarsAlereon 2 days ago | parent | prev | next [-]

From what I understand, the main goal is to fix the problem that non-native (1:1 pixel mapping) resolutions and scaling look worse than native. This is a problem when you ship high-dpi displays that need UI scaling in order for things to be readable. Apple's solution was to render everything at a higher, non-native resolution so that images were always downscaled to fit the display.

So to oversimplify, Windows can have a problem where if you are running 1.5X scaling so text is big enough, you can't fit 4K of native pixels on a 4K display so videos are blurry. If instead you were rendering a scaled image to a 6K framebuffer and then downscaling to 4K, there would be minimal loss of resolution.

▲

adrian_b 2 days ago | parent | next [-]

I do not know who was the moron that first used scaling in conjunction with displays having a higher resolution, but this is a non-solution that should have never been used anywhere.

Already more than 35 years ago the correct solution was used. For text and for graphics, the sizes must be specified only in length units, e.g. in typographic points or millimeters or inches, e.g. by configuring a 12-point font for a document or for an UI element. Then the rasterizer for fonts and for graphics renders correctly everything at a visual size that is independent of the display resolution, so it is completely irrelevant whether a display is HiDPI or not.

To combat the effect of rounding to an integer number of pixels, besides anti-aliasing methods, the TTF/OTF fonts have always included methods of hinting that can produce pixel-perfect characters at low screen resolutions, if that is desired (if the font designer does the tedious work required to implement this). Thus there never exists any reason for using scaling with fonts.

For things like icons, the right manner has unfortunately been less standardized, but it should have been equally easy to always have a vector variant of the icons that can be used at arbitrary display resolutions, supplemented by a set of pre-rendered bitmap versions of the icons, suitable for low screen resolutions.

I am always astonished by the frequent discussions about problems caused by "scaling" on HiDPI displays in other operating systems, because I have been using only HiDPI displays for more than a dozen years and I had no problems with them while using typefaces that are beautifully rendered at high resolution, because I use X11 with XFCE, where there is no scaling, I just set the true DPI value of the monitors and everything works fine.

	▲	nottorp a day ago \| parent [-]
		> Then the rasterizer for fonts and for graphics renders correctly everything at a visual size that is independent of the display resolution, so it is completely irrelevant whether a display is HiDPI or not. Well that sounds great in theory, but then you'll get only one button per screen on your laptop and maybe two on your desktop. More likely one and a half.

▲

tgma 2 days ago | parent | prev [-]

> From what I understand, the main goal is to fix the problem that non-native (1:1 pixel mapping) resolutions and scaling look worse than native.

That would be my instinct as well, but the author seems to be delibarately doing the exact opposite. Trying to force a 2x HiDPI and then downscaling to native display resolution whereas he could have just done a 1:1 LoDPI rendering. What you get in the end is some equivalent of hack/brute-force smoothing/antialiasing of what was rendered in the downsample.

▲

adrian_b 2 days ago | parent [-]

The author said that the problem is that Apple has introduced a size limit for the display (3360x1890) that is lower than the size of the actual display, which is a standard 4k display (3840x2160).

So 1:1 rendering can cover only a part of the screen, while the remainder remains unused.

If the maximum size limit is used but applied to the entire screen, it does not match the native resolution so interpolation is used to convert between images with different resolutions, blurring the on-screen image.

All the attempts were done with the hope that there is some way to convince the system to somehow use the greater native image size instead of the smaller size forced by the limits.

	▲	sgerenser a day ago \| parent \| next [-]
		Nope, you completely misread the post. All Mac’s including M4s and M5s can run at a 1:1 4K resolution all day long filling the screen completely. That’s not what the OP wanted though, they wanted to render at 8k (roughly 7680 px by 4320 px), then downsample that by 2x in each direction to map to the 4K display. Supposedly to make things “look better” than rendering at the native resolution but it sounds insane to me.
	▲	tgma a day ago \| parent \| prev [-]
		That does not seem to be the case for my M4 Mac mini in native "low-DPI" mode with a 4K display, so I think the problem only appears in HiDPI (7680x4320 framebuffer downscaled back to 3840x2160 only). The author seems to be confirming the max intermediate framebuffer is 6720 pixels wide.

▲

onetom 2 days ago | parent | prev [-]

i'm also using https://betterdisplaymac.com/ for this purpose.

even on a native 2K monitor, having a virtual 5K frame buffer downscaled to 2K yields perfectly enjoyable results, compared to how macOS' native 2K image would look like; it causes eye-bleed :)

	▲	jasomill 21 hours ago \| parent [-]
		Assuming by 2K you mean 2560x1440, I also prefer non-integer HiDPI 2560x1440 mode over both native and HiDPI 1080p modes on my large (55”) 4K display, and the non-integer scaling is only rarely a problem.