Yes 
Threads are costly. They mean synchronization to take care of, they use up some memory, and they make software more complicated (unless you use a language like Erlang that is written with threads in mind).
I think this should start by defining a file format and writing a simple renderer for it (even if it is slow). Then see if you manage to make a significant difference to the font size compared to the existing offerings. If you don’t, there is no point in trying to make it as fast than the existing systems. And if your goal is to make things faster than existing systems, that probably means making the font files larger, not smaller, if we assume the designer of the truetype format knew a bit about what they were doing.
1 Like
Thanks for helping me keep sight of the priorities, @PulkoMandy . If the file is smaller, the hard drive latency (or lack thereof) may make a bigger difference anyway.
PDF is basically a tokenized postscript. We use them both for printing.
Instead of replacing HarfBuzz, I might consider a backward-compatible Graphite2 replacement. HarfBuzz seems to be more for the Unicode parsing. I’ll have to look into it more.
Starting the Journey
I’ve forked the WonderBrush v3 sources as a starting point. After reading some development docs, rendering reusable “blocks” as bitmaps and incorporating Icon-o-Matic features were already on the agenda. Thanks @stippi !
I might just remove the text gadget for now from my fork. Glyph-o-Matic, as I am now calling it, will be mainly for rendering GUI elements and font glyphs. Rendering a font glyph inside a font glyph gets uncomfortably recursive. 
4 Likes