Performance issue

[simoncozens]

The problem we're going to have with this font is that it's really slow to render. We have a 720k COLR table for a 920k font, and right now changing the sliders in FontGoggles is taking a full two seconds for a single glyph; six seconds for a string of six glyphs. Even with blackrenderer things are bad:

*$ time blackrenderer fonts/ttf/variable/Bitcount_Grid_Single4-Color\[wght,OPEN,SHPE,slnt,BG-S,BG-X,BG-Y,FG-S,FG-X,FG-Y\].ttf ABCDEFG /tmp/shape.png
blackrenderer  ABCDEFG /tmp/shape.png  2.58s user 0.18s system 229% cpu 1.205 total

COLRv2 would help a lot. I wonder if two layers are actually going to be feasible, or if we're going to have to wait for COLRv2 to land.

[simoncozens]

Actually come to think about it, COLRv2 won't help at all, since we're drawing individual sets of dots for each glyph, so there's no templating possible. Urgh.

[petrvanblokland]

It seems to be much faster in Chrome, which I have been using for testing all the time. And that is supposed to be the real use, not FontGoggles. Just van Rossum also through it to be interesting to check what makes FG take much longer for it.

One solution could be to scale it down to one layer or to reduce the amount of elements per layer. In fact a lot of rendering is wasted outside the clipping of the pixel shapes. I don't know how intelligent the render engine does the clipping on glyph masks.

What is "good" about finding the limits (creating a benchmark for COLRv1), is that I don't need to worry about the design of more layers or elements. :)

Maybe we also could reduce the amount of gradients. I guess those take much more time to render than plain color elements.

P

On Aug 9, 2023, at 2:36 PM, Simon Cozens @.***> wrote:

The problem we're going to have with this font is that it's really slow to render. We have a 720k COLR table for a 920k font, and right now changing the sliders in FontGoggles is taking a full two seconds for a single glyph; six seconds for a string of six glyphs. Even with blackrenderer things are bad:

*$ time blackrenderer fonts/ttf/variable/Bitcount_Grid_Single4-Color[wght,OPEN,SHPE,slnt,BG-S,BG-X,BG-Y,FG-S,FG-X,FG-Y].ttf ABCDEFG /tmp/shape.png blackrenderer ABCDEFG /tmp/shape.png 2.58s user 0.18s system 229% cpu 1.205 total COLRv2 would help a lot. I wonder if two layers are actually going to be feasible, or if we're going to have to wait for COLRv2 to land.

— Reply to this email directly, view it on GitHub https://github.com/petrvanblokland/TYPETR-Bitcount/issues/7, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAC4DQKOLGDNQK22LAMSWFLXUN73JANCNFSM6AAAAAA3J5543M. You are receiving this because you are subscribed to this thread.

---

Petr van Blokland Mastodon @. Instagram @petrvanblokland Intentionally not on FaceBook since 1990 and Twitter stopped. @. | designdesign.space | typetr.com mobile +31 6 24 219 502

Claudia Mens | @.*** mobile +31 6 41 367 689

Rotterdamseweg 150-d 2628 AP Delft The Netherlands

[simoncozens]

It might be a blackrenderer issue (which is what's stalling FontGoggles).

I don't think the rendering outside the clipping mask is a big problem; you can technically set a ClipList table to set the bounds of each glyph to help the renderer, but it doesn't look (from the blackrenderer code) that this will do very much in our case: if there are no ClipList entries, it just uses the Harfbuzz extents, which is what we would be feeding it anyway.

Doing some profiling on the blackrenderer code, the problem seems to be that the call to _drawGlyphOutline is slow; there's no caching, so we have to draw our pixel element 40 different times per glyph, going back and forth between Harfbuzz and our pen routines each time.

[simoncozens]

Okay, I've fixed a lot of the performance issues with the font and managed to make it considerably smaller too. I can't fix the performance issues with blackrenderer. :-)