When adding sparse ranges the cartesian product of range combinations
was explored to find intersections, which is pretty awful if there
are 1 million entries to be inserted.
This commit employs binary search to reduce the complexity, at
the expense of requiring that the internal range array is sorted.
- If possible use fontconfig to obtain character coverage instead of
going through all glyphs using freetype.
- `FT_Get_First_Char` typically returns ranges of continuous glyphs itself
and it is far cheaper (I measured a speedup of about 7 times while
catting a large file with lots of funny unicode) to add a range to the
glyph coverage instead of adding each glyph individually.
- Permit adding a range to a RangeSet without performing checks to speed
up things even further.
This commit adds support for computing the codepoint coverage for fonts
loaded from font-dirs and the built-in, in-memory fonts.
What this means is that if you have eg: a font with chinese glyphs in
your font-dirs but not explicitly listed in your wezterm config, if
chinese text is rendered and no match from your config is found, wezterm
will be able to find the font from your font-dirs and use that
implicitly.
Computing the codepoint coverage is relatively expensive so we defer it
until we need to perform it, and cache it.
Record a notion of the state of the invalidations that we've sent
to the client so that we can skip sending updates if nothing has
changed since the last push.