> Sorry to sound like an old fart, but computers have been doing this for years
With the CPU, yes, but not on the GPU. The point is that we've generally been limited to doing this serially, which ties into this:
> and no, caching rendered glyphs does not eat huge amounts of memory
It does the moment your user starts to zoom rapidly in and out like in this demo and you want smooth zooming without rendering artefacts, potentially with multiple fonts, and potentially dealing with large font sizes and multi-colour fonts.
I'm an old enough fart myself to know that at least the earliest ARMs with RiscOS (as well as the Amiga's) had little enough memory/cpu bandwidth to make fast, smooth zooming of lots of text a challenge even with pre-cached font-bitmaps. And it took a long time before most systems would have enough memory to be able to treat this that casually.
> Of course, the font renderers have gotten smarter, and of course, screen resolutions have increased, but the difficulties inherent in font renderering are all at the small scale, where you want text to remain crisp even when using only a few pixels.
I've written terminal emulator code, and I've written GUI toolkit code several times, and text rendering speed on CPUs is still something that needs a lot of optimization to avoid it being a bottleneck. At small sizes you obviously can easily afford to cache, but then you end up having many more small blits - the overhead is still painful but for different reasons. E.g. intelligently blitting the existing window content to minimize re-rendering tends to be a major speedup vs. re-rendering every glyph even with fixed width bitmap fonts.