As I understand subpixel anti-aliasing is gone, but grayscale anti-aliasing remains.
Basically.
Apparently Mojave defaults to not having this on as users with a non retina screen need to enable this.
No, what people are tweaking with the command line is mostly the thickness of the rendering.
(edit)
The above isn't quite right. CGFontRenderingFontSmoothingDisabled does apparently bring back subpixel rendering for non-layer backed views. (Or possibly for applications not linked against the 10.14 SDK.) It
But you raise a different issue. You seem to be saying subpixel anti-aliasing, though available, wasn’t being used or capable of being used in some situations. So my question is, how often and where does this come into play? Are you saying the menu bar is an example of a UI element that did not have subpixel anti-aliasing even in High Sierra?
Yes.
From 10.0 on, text on an LCD display got "LCD font smoothing", which takes advantage of a known subpixel layout (a certain arrangement of red/green/blue elements within the LCD panel) to make the text crisper. This takes place on the CPU, and requires that the LCD matches that assumed layout, that the background on top of which the text is rendered beforehand, and some other aspects. (It gets complicated when, say, you have multiple displays that work differently.) This is part of what Quartz/Core Graphics does out of the box.
Critically, for this subpixel trick to work, you need to know in advance what your character glyph looks like, and which subpixels it will fall onto.
From 10.5 and iOS 1.0 on, with Core Animation, an alternative path is offered, where graphics are layered and rendered straight on the GPU. The big benefit is much higher performance. However, text rendered with Core Animation doesn't support such subpixel rendering at all. It basically can't (at least not easily) — as a tradeoff of the performance being better, you can no longer predict the background underneath a text, and as a result, the above will no longer work: you'd need to alpha-blend all elements in advance in order to know how to render the glyph, but at that point, you would throw the performance benefit out of the window.
For macOS, Core Animation was mostly opt-in — developers decided whether they want their views to be "layer-backed" (i.e., with Core Animation enabled) or not. For iOS, it was always on.
One of the effects introduced in 10.5 Leopard is the menu bar has been translucent. (Between 10.5 and 10.9, this could be turned off; this is no longer possible since 10.10 Yosemite.) But, for performance reasons (and perhaps also to show off the power of Core Animation), that translucency took place on the GPU, using Core Animation. Hence, if you have that on, which these days you definitely do, the menu bar is never ever subpixel-rendered. Not in 10.14, but also not for many releases before that.
This matters a lot less on retina displays because the pixels are already small enough for the subpixel effect to be of much additional help. But for non-retina displays, it's a bit unfortunate.
Now here's the part that's semi-informed speculation: I believe the two changes in 10.14 are:
- several cases where layer-backed views used to be opt-in for developers no longer are, as the legacy paths are no longer beneficial or necessary. Those views automatically become layer-backed, and thus, among other things, faster. But, as a side-effect, they also lose subpixel rendering.
- to make things look more consistent, even text that would support subpixel rendering no longer is rendered such