I'm curious - when you were doing research into the mechanics of hinting options, did you stumble onto any relevant discussion around allowing custom pixel geometries to be defined, to enable hinting on modern OLED / WRBG displays? There's a good thread on the topic here[0], with some people referring to it as 'ClearType 2' on the MS side [1]. On the oss side I know FreeType theoretically supports this[2], but I can't quite figure out how relevant the FreeType backend is to this most recent work.
It would be nice if monitors exposed info about subpixel geometry as part of their EDID data. An alternative would be to capture it in a hardware database.
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.
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.
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.
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.
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.
For one, subpixels aren't just lines in some order - they can have completely arbitrary geometries. A triangle, 3 vertical slats, a square split in four with a duplicate of one color, 4 different colors, subpixels that activate differently depending not just on chromaticity but also luminance (i.e., also differs with monitor brightness instead of just color), subpixels shared between other pixels (pentile) and so on.
And then there's screenshots and recordings that are completely messed up by subpixels antialiasing as the content is viewed on a different subpixel configuration or not at 1:1 physical pixels (how dare they zoom slightly in on a screenshot!).
The only type of antialiasing that works well is greyscale/alpha antialias. Subpixel antialiasing is a horrible hack that never worked well, and it will only get worse from here. The issues with QD-OLED and other new layouts underline that.
The reason we lived with it was because it was necessary hack for when screens really didn't have anywhere near enough resolution to show decently legible text at practical font sizes on VGA or Super VGA resolutions.
Subpixel AA is still more readable for non-HiDPI LCD screens, which are still the majority of desktop monitors sold today. It did work well enough for people to be using it for so long, and the situation with screens on desktop has mostly not changed.
It also works great with almost but not-quite HiDPI screens such as commonly available and cheap 4K 27" monitors. You can scale them at 150% and with ClearType it looks as good as super expensive 6K Mac screen.
In fact since cleartype effectively triples resolution I guess you get quality of 12K display?
It does not triple resolution. Subpixel rendering can only be used to smooth full pixel lines - this introduces color fringing on the sides of font glyphs, but one that can sometimes be ignored when the smoothed lines are thick enough to distract.
If you used subpixel rendering to render lines of fractional pixel thickness, it would just appear as a single-pixel line of the wrong color. The same happens if you render line thicknesses up to 1 1/3 pixels wide, but offset to not match any pixel boundary.
At the same time, subpixel antialiasing can only be used with a specific subpixel layout, in the direction sof the subpixels. For regular desktop LCD panels, this means smoothing of vertical lines only, making characters like "o" look funky and uneven.
With that in mind, a 4k panel with subpixel antialiasing does not look anything like a 6k panel with greyscale antialiasing ("super expensive mac screen" is not relevant, apart from display technology differences not related to resolution or aliasing).
I agree, although this isn't as noticeable as it is on a true low dpi screen. In the monitor market anything higher resolution than a 27 inch 4K tends to be ludicrously expensive, and won't be an option for most people. With Windows having pretty functional fractional scaling, I doubt anything higher than 4K will ever become mainstream, since at the distance you are using your desktop monitor, more resolution is of limited value.
Subpixel AA does not have significant benefits over greyscale AA on 1440p or similar displays, and it always have all the downsides. If you're rocking a large 1080p display and never share your screen (including screenshots), sure.
As the field of view taken by pixels decrease (DPI only has meaning when combined with distance to retina), anti-aliasing becomes less and less relevant. But until then, greyscale remains the lesser evil.
This is great work btw.
[0]: https://github.com/snowie2000/mactype/issues/932
[1]: https://github.com/microsoft/PowerToys/issues/25595
[2]: https://freetype.org/freetype2/docs/reference/ft2-lcd_render...