Re: hb-raster: a new CPU rasterizer

Behdad,

> With help from my AI assistants, I finally put together a rasterizer in H=
arfBuzz, in a new harfbuzz-raster library. Accompanying the rasterizer is a=
 COLRv1 color-font renderer, but I like to focus on the rasterizer in this =
email:

Congratulations!

> While it was designed from scratch, the general algorithm is similar to F=
reeType's, that is, a coverage based AA rasterizer. From there though, diff=
erent approaches are taken. The end result is that the code runs 2x or more=
 faster than FreeType's in my testing.

Do you mind dissecting the performance of your rasterizer a bit
further with the perf counter? This would help to compare performance
more carefully. For example,
$ perf record bin/ftbench -f2 -s32 -bc tahoma.ttf
$ perf report

  26.49%  ftbench  libfreetype.so.6.20.4  [.] gray_render_line
  19.30%  ftbench  libfreetype.so.6.20.4  [.] gray_set_cell
  18.37%  ftbench  libfreetype.so.6.20.4  [.] gray_convert_glyph
   7.78%  ftbench  libfreetype.so.6.20.4  [.] TT_Load_Simple_Glyph
   4.92%  ftbench  libfreetype.so.6.20.4  [.] gray_conic_to

This shows how FreeType rasterizer spends its time at 32 ppem. After
subtracting other activities, the curve and line integration is about
40%, the pixel list management is 30%, the final sweep is 30%. I
suspect that the linked list management is what you avoid at the
expense of more memory usage, with a faster sweep too.

> I long had intuited that a tightly woven rasterizer code will perform rea=
lly well, and this experiment seems to prove that. The code is very short (=
~1000 lines) and readable:
>
>   https://github.com/harfbuzz/harfbuzz/blob/main/src/hb-raster-draw.cc

Thanks,
Alexei