Ya, I'm pretty sure font discovery would be fast because it's just loading the database of font names, which is probably just a walk through the /usr/share/X11 fonts directory to gather names, or perhaps there's a font daemon has that list pre-loaded.

fl_font() is surely the operation that involves actually loading the font, and pre-rendering all the glyphs at the size you request, as I think that has to be done in advance (turning all the TTF vectors/curves into pre-rendering pixels, if I understand how the font system works.. just guessing)

So a call to fl_font(somefont, 14) would I think tell the font system to load and pre-render that entire font's glyphs at the font size you specify, which would render out each glyph's vectors and curves into a pixel cache (just guessing), so that from then on, any rendering of that font will happen quickly. So that one fl_font() call is going to cause all that; high cpu and probably high memory too.

I guess I'm not sure if you're asking if that process can be optimized by FLTK? I'm not sure it can, as that load/pre-rendering process would all be handled by the font subsystem, and the only way around it would be, I think, to "schedule" pre-rendering of fonts on demand, rather than all at once, which would probably cause lots of hiccups each time a new glyph is rendered for the first time, causing sluggishness spread out over the app's execution time, rather than all up front. Or something like that.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.