Show HN: GPU text rendering with vector textures

I have no argument against that kind of font-atlasing as a process; it's fairly more stateless, more like a secret cache inside the black box of the glyph-rendering kernel.

Sure, but that uses a lot of memory, and initial pageload is going to be really slow. Especially when you consider you need to generate mipmaps if it's really high resolution, or else blow out your GPU's L1/L2 cache in FS execution.

> Doesn't that approach win over re-rendering all the text from a font-atlas every frame?

Not significantly, in my experience. Assume, in the simple case, that you're just rendering a bunch of text with no overlap. In that case, the only thing that tiles buy you over rerendering all the text from an atlas is decreased vertex count. You're still touching the same number of pixels in the FS and ROP units either way: you just do so with more vertices in the texture atlas case and fewer vertices in the tiling case. Now consider that creating and maintaining the tiles has costs over maintaining the glyph atlas (which you have to do either way): you have the memory of the tiles, the overhead of creating and switching FBOs, lots of little textures to keep around (which in naive implementations results in tons of state changes), and extra draw calls to render the tiles after rendering the content.

> why do browser rendering engines use tiles?

Mostly because it was an easy way to fit GPU-accelerated panning and zooming into the existing, originally CPU-based, rendering architectures that browser engines used (and still largely use). Tiling was popularized by Mobile Safari on the iPhone in 2007 as an easy way to avoid repainting the entire page on the CPU every frame when the user performed touch gestures. I don't think it's necessarily a globally optimal decision.

Hinting was necessary back before good antialiasing existed but I don't think many renderers use it now. This technique renders each glyph differently according to its subpixel position - completely the opposite approach to hinting, which snaps features of the glyph to integer positions on the pixel grid.

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.

Well yes, that'll wipe out the cache hit rate, but when has the use case of 'zooming rapidly in and out of text' ever been a particular point on contention for any application? Even the original iphone's web zoom was good enough, a smooth zoom with temporarily blurry text until you pick a good zoom point. Seems like a very obscure niche functionality to optimise, one where no-one apparently cares about right now.

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.

True enough! I can't even think of any app that had smooth zooming... most apps had a zoom factor (e.g. x1, x2, etc) that would work perfectly with a font cache. The main crunch point was the simple, intelligent, partial rendering of text as you pan around a page.

At small sizes you obviously can easily afford to cache, but then you end up having many more small blits

Going back to my nostalgia for RiscOS, I wrote a dumb anti-aliased font renderer that would draw fonts dot-by-dot rather than by blitting a 2d transparent bitmap to the screen, it turned out to be massively faster than even a simple cached bitmap font renderer, even at larger sizes. Definitely not a good approach today with higher-res screens though... (and the storage format was massively wasteful at larger sizes)

Terminal text rendering is a bone of contention for me, as it's frustrating how some modern-day terminals can be utterly appalling at doing their job (e.g. typing 'dmesg' and having to wait several seconds for it to complete), so I'm all in favour of anyone who takes an interest in making it fast. Most terminals unfortunately seem to try and redraw every new line to the screen, rather than realising that they've got another 10000 lines to print and perhaps the user might be content with a (say) 30fps update interval...