131–140 of 180 posts
Earlier quoted context omitted.
Apple never supersamples by 2x. Default MacBook Air scaling was around 1.1x iirc.
It’s actually around 1.5x for the default resolution out of the box and 1.3x for “more space” setting on m1/m2 MacBook Air. 1.1x supersampling on Macs makes it worse because down sampling to pixel alignment becomes a hot mess.
Earlier quoted context omitted.
I don't expect emails to get through to busy CEOs of huge companies like Apple unless you're really lucky and they make it through some automation, but I have dropped him an email just in case. I guess you never know.
Has anyone tried sending an email to Nadella telling him that Windows is terrible now? What if that was all it took.
Earlier quoted context omitted.
It’s actually around 1.5x for the default resolution out of the box and 1.3x for “more space” setting on m1/m2 MacBook Air. 1.1x supersampling on Macs makes it worse because down sampling to pixel alignment becomes a hot mess.
Fine, you made me look it up. M1 Air defaults to 2880x1800 on a 2560x1600 display, which is a 1.125x scaling. Nowhere near the 1.5x you claim.
When you set it to "more space" it becomes noticeably slower, but not blurry.
Earlier quoted context omitted.
Yeah. I don't get it. If you've got a 3840x2160 display, intended use on macOS as a 1920x1080@2x display, what is the advantage of using a 7680x4320 buffer? Everything is drawn at twice the width and height - and then gets scaled down to half the width and height. Is there actually a good reason to do this? (I use my M4 Mac with 4K displays, and 5120x2880 (2560x1440@2x) buffers. That sort of thing does work, though i…
> what is the advantage of using a 7680x4320 buffer? Everything is drawn at twice the width and height - and then gets scaled down to half the width and height. Is there actually a good reason to do this? Text rendering looks noticeably better rendered at 2x and scaled down. Apple's 1x font antialiasing is not ideal. Especially in Catalyst/SwiftUI apps that often don't bother to align drawing to round points, Apple's…
You might need a higher quality usb cable. I run ok with LG 5k display and MacBook Pro m4 max.
Earlier quoted context omitted.
Then complain about that. That would make a much more sensible blog post and discussion. Asking for a crazy workaround to a sane problem isn't a great way to get good results, especially with Apple. Beyond the obvious performance pitfall, this scale up to scale down approach will also destroy the appearance of some controls. There is some UI that aims for 1px lines on hidpi modes that will get lost if you do this. It…
The crazy workaround only needs to be done because of what Apple did probably around a decade ago and probably already heard a bunch of crying about and didn't care. No one removed subpixel antialiasing on their own, we do this bullshit because Apple forced us to to make text look halfway decent.
If you haven’t personally filed a bug report at feedbackassistant.apple.com, I recommend that you do so. Title it something like “Poor text quality on LoDPI display”, file it in the Displays component, and in the description explain what you’re seeing. Here’s the critical part: you want to attach images showing what looks bad and what looks better, and why the current behavior is a regression and since when (earlier macOS versions for subpixel AA, earlier GPUs for 2x 1x mode). If possible, use the same display, but get an image of historical macOS when it had subpixel AA, macOS with this 2x 1x mode, Windows 11, and then current macOS at the standard 1x mode. I’m not sure screenshots will capture it, you’ll probably need to use a camera.
I know how they think at Apple. If you come at them with a bug written like OP’s blog, they are going to say it behaves as designed. To get them to fix something, you have to be descriptive about what the real problem actually is: the text rendering looks bad. Then you have to explain what used to work and what you’ve tried and bring receipts (the images). Don’t write a novel; write the shortest bug that fully describes the real problem, includes all of the relevant information including macOS versions, hardware info, and display model, and the evidence of the problem, but don’t include a bunch of emotional text or extraneous information (like SkyLight framework reverse engineering stuff).
Now you might say, “I’m not Apple’s free QA”, and you’ll be right. But, consider that you’re spending this time complaining about a problem online and you’ve spent good money on a display you’d like to use and it’s not working the way you want. Fair or not, you care about the outcome, and at this point you might as well take my advice and file a strong bug to make your case. Dupes help, OP should file one too, but be descriptive about the real problem, not proscriptive about bringing back the crazy workaround that they likely intentionally disabled because on the face of it, it makes no sense.
I do know that they read user bugs in the Displays component, because I have filed a few in there recently and they got fixed and they followed up with me about where they were fixed.
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?
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 ha…
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.
Earlier quoted context omitted.
27" 4k is totally fine on Windows 11 (not a gamer). Everything is sharp at 150% scale.
Windows does ha not have this issue.
Earlier quoted context omitted.
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 ha…
> 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 equivale…
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.
> This aligns with our findings. The M4/M5 DCP firmware implements a conservative framebuffer pre-allocation strategy that: > Caps the HiDPI backing store to approximately 1.75x the native resolution (6720x3780 for 3840x2160 native), rather than the 2.0x needed for full HiDPI (7680x4320) So, that could be an off by one bug? That might be testable by tweaking the system to think the display supports an even higher res…
I tried quite a few things in the "Advanced" section of BetterDisplay - is there something specifically you're suggesting?