Benchmark Mojave's text painting performance

[raphlinus]

OS 10.14 Mojave is making substantial changes to text painting. In particular, RGB subpixel painting is now off by default, though it is possible to turn it back on.

I haven't experimented with 10.14 yet, but have dug pretty deep into 10.12 and 10.13 (no significant differences between the two). Both rely on software rendering, and, though it uses SIMD, it comes nowhere near what a GPU can do. Part of the reason the code is slow is that it does gamma-corrected blending (see http://blog.johnnovak.net/2016/09/21/what-every-coder-should-know-about-gamma/ though I don't endorse everything said there). Note that there are multiple code paths depending on whether the bg and fg colors are pure black/white (as is often the case in macOS) or arbitrary colors (common with styles/themes), and this should be measured in a benchmark.

Without RGB subpixel rendering, it's easier to use a GPU; painting text should just be an A8 texture draw. Gamma questions remain, but GPU's are certainly able to do gamma corrected blending, either in a shader or by setting the colorspace of the buffer.

If Mojave has fast text painting, then we probably want to revert our OpenGL renderer. There are a fairly large number of papercut issues, including #266, imperfect bidi (see #263), IME positioning, and I'm sure a few more. In addition, OpenGL is deprecated, so it's not really a good long term solution.

In addition to just painting, it's worth digging into whether the macOS performance bug underlying #20 has been fixed. Again, if not, we probably want to start doing our own logic.

If Mojave has slow text painting, then I think a long term solution is to write a text surface in Rust, backed by a suitable portable GPU-accelerated API (WebRender would work well, and porting the logic in the existing OpenGL renderer on top of gfx-rs would also make lots of sense). Such a surface could be used by multiple front-ends. In addition, moving the line cache logic into Rust as well could avoid much of the difficulty with slow JSON in Swift (see #102). But this is a lot of work and very much a long term prospect.

Having benchmarks would be super useful. Marking as "help wanted" because it doesn't require deep knowledge of the xi-mac codebase, can be done as a standalone project; verifying #20 is pretty much a case of running the code in the linked radar.

[jansol]

FWIW the radar in #20 gives me sub-second times for all of its test cases:

24 bytes took 3.3974647521972656e-05
16384 bytes took 0.009947061538696289
32768 bytes took 0.017521023750305176
65536 bytes took 0.03349804878234863
131072 bytes took 0.06961405277252197
262144 bytes took 0.14702904224395752
524288 bytes took 0.3142690658569336
1048576 bytes took 0.5723930597305298

This is on macOS 10.14.2 with subpixel smoothing off.

[jansol]

I have no idea how to even start benchmarking the actual text painting though.

[jansol]

@raphlinus do you have some concrete steps for benchmarking Mojave's text painting? (I'm guessing via NSTextView) I should have time to look into this a couple of weeks down the road.

[raphlinus]

The quick answer is no, not NSTextView, that's too high level, we need to create an NSMutableAttributedString, then create a CTLine from that, and finally draw lots of CTLine's in a custom NSView.

Another interesting thing about benchmarking is that in a software renderer, black-on-white is a special case and runs faster than arbitrary bg and fg colors. If it's hardware rendering, we shouldn't see that. It's my understanding that subpixel RGB hasn't been removed from mojave but is no longer the default? Should try with both settings.

[jansol]

Just to make sure, would we still be using NSTextView for xi-mac in the end if the CTLine thing is fast? Otherwise there isn't much point as we would still have to deal with the IME stuff ourselves.

[raphlinus]

No, I don't think we can use NSTextView, as I think takes over too many functions we need to hook directly. Likely we would continue using a custom view.