[jsheard]

AIUI the trend has been towards GUI frameworks dropping support for subpixel AA altogether, since that simplifies so many things[1], so I'm not holding my breath for the current limitations around unusual subpixel layouts being fully resolved on any platform. Apple made the switch to greyscale-only AA years ago, Microsoft is mid-transition with their newer GUI toolkits ignoring the system Cleartype setting and always using greyscale AA, and the GTK renderings in the OP are greyscale too. They're assuming that people will just get a HiDPI display eventually and then greyscale AA is good enough.

[1] https://faultlore.com/blah/text-hates-you/#anti-aliasing-is-...

[NoGravitas]

Even on a screen with not-particularly-high DPI, grayscale AA is fine. Subpixel AA was a brilliant idea for the displays of 2005 (72-96 DPI), but it came with lots of downsides (like color fringing on dark backgrounds, or for users with astigmatism). Grayscale AA drops both the benefits and the drawbacks, but even at like 100 DPI, the difference is very marginal.

[alwayslikethis]

At 110 DPI (27 inch 1440p) it's not that marginal for me. Even looking somewhat closely the difference is quite obvious. Subpixel AA is much more readable if the font size is small, and still looks sharper for most interface fonts.

[zozbot234]

Color fringing on dark backgrounds is yet another artifact of anti-aliasing being done with a misconfigured gamma. Regardless you can configure subpixel rendering to minimize these fringing effects.

[namibj]

I'll repeat my wish for a mass-production Bayer matrix TV to offer alternative firmware/a special mode where it goes _very_ dumb (though an optional overdrive setting (assuming it's an LCD) as a toggle or slider or so would be welcome; it's a massive pain to DIY and shouldn't get on the way of anything but FreeSync/VRR) and claims to be a monochrome panel at the true native resolution & bit depth on DisplayPort.

You'd want to render to that grid; then apply bayering fused with color mapping. No need to transmit 3x the data over the cable. And with a hint of sufficient software support (I think the high DPI stuff might (almost?) suffice already!), I'd actually prefer such a screen over a traditional vertical bars of RGB (or BGR, as I'm currently suffering; sadly the thermal design of the screen won't allow me to safely just rotate it to"wrong" landscape) LCD monitor... provided both have the same number of subpixels.

Probably bonus for a 4th deep cyan pixel color in place of a duplicate green to get a wider gamut. Or something similar in spirit.

A device like this would allow hobby developers to bring the software/driver support up to "daily driver, no regrets" levels.

Similarly I still wonder why no OLED seems to have shipped a "camera-based motion/pan/defocus self-calibrated" burn-in scan& compensate function where you just every ~100 hours move a cheap camera on front of the screen following the on-screen movement directions, to mechanically create an opportunity for the cheap sensor to be calibrated, and then use this freshly calibrated brightness sensor to map the OLED panel and make up for that the exact burn-in is very hard to simulate, but is required precisely to compensate/pre-distort without leaving visible residuals from incomplete/imperfect cancellation between the pre-distortion and the burned-in pattern.