Use supported codepoints instead of scripts in Monospace fallback

[MoSal]

This should/could improve fallback order.

This could also probably be utilized for non-Monospace fallback too.
But I didn't want to touch that code to avoid accidentally breaking
anything.

[jackpot51]

Make sure to format with cargo fmt and then run the tests with ./test.sh

[MoSal]

Formatting done.

As for tests, these 6 fail on my system with and without this change. They trigger the "no default font found" expect() from src/shape.rs:

failures:
    test_arabic_paragraph_rendering
    test_arabic_word_rendering
    test_english_mixed_with_arabic_paragraph_rendering
    test_english_mixed_with_hebrew_paragraph_rendering
    test_hebrew_paragraph_rendering
    test_hebrew_word_rendering

[MoSal]

Pushed the Emoji commit here because the same code block is touched.

[MoSal]

Converted to draft until wide Monospace cases are sorted out properly.

[MoSal]

Removed the emoji change in favor of #216.

[vorporeal]

Was any performance analysis done on this change? I'm noticing in CPU profiles for our application that a lot of time is spent iterating over codepoints in subtables during Font construction - for extensive unicode fonts, this could end up doing significantly more work than the previous code.

[MoSal]

Was any performance analysis done on this change? I'm noticing in CPU profiles for our application that a lot of time is spent iterating over codepoints in subtables during Font construction - for extensive unicode fonts, this could end up doing significantly more work than the previous code.

• Is that with Faster mono fallback #242 applied or not?
• By "during Font construction", do you mean font system initialization?

After #242, performance should be fine. There is bit more work done in font system initialization. But after that, performance shouldn't be an issue. I perf'ed this in cosmic-terminal. Feedback from other use cases would definitely be appreciated.

[vorporeal]

We're using the latest published version (0.11.2), which doesn't include #242.

Should there be a new release cut and pushed to crates.io that contains the performance fix?

[MoSal]

We're using the latest published version (0.11.2), which doesn't include #242.

Can you check with a version that includes it?

Should there be a new release cut and pushed to crates.io that contains the performance fix?

That decision resides with @jackpot51. I'm just a random contributor.

---

Still interested in learning more about the use-case where this caused noticeable regression. Is monospacity required for the use-case, or was it just a Monospace font that happened to be selected? Are very long lines involved? Are continually updating text buffers involved? ...