bug#71454: 30.0.50; Performance issues with font selection

[Kai Ma <justksqsf@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2603 bytes --]


> On Sep 27, 2024, at 08:32, Eli Zaretskii <eliz@gnu.org> wrote:
> 
>>> I have currently (length (font-family-list)) = 582 font families
>>> installed. And whenever I input some ununsual characters, Emacs will
>>> freeze for seconds until I am able to do anything else.  Worse, the
>>> freeze delay for each character will add up.  And whenver the face
>>> changes (including hl-line-mode), or I switched to another buffer for
>>> some time, there will be a delay again.
> 
> This part, about _any_ unusual characters causing a significant delay,
> seems to imply that the default fontset is not set up correctly on
> your system (or maybe in general on macOS), or perhaps that the way
> the fontsets are used on macOS is very different from other systems.
> For starters, are the fonts that Emacs selects for the characters you
> used for testing different from the fonts defined by fontset-default
> for those characters?  If so, what happens if you modify
> fontset-default (using set-fontset-font) to specify for these
> characters the same fonts as what Emacs selects with the default value
> of fontset-default? does font selection become much faster (it
> should)?

Yes, if I manually set the font, it becomes instant.

> If specifying the precise font in the fontset doesn't speed up font
> selection, then something is very wrong with how fontsets are used on
> macOS.  Emacs comes with the default value of fontset-default that is
> already configured for many characters, and the ones you show should
> be included.  So I'm puzzled why you experience such long delays when
> some of those characters are used.
> 
> It could also be the matter of selecting the default face's font.  For
> best results, it should be a font that covers many popular scripts, at
> the very least Latin, Cyrillic, and Greek.  Judging by the "unusual"
> characters you show, it sounds like Latin characters are not well
> covered by your default face's font?  If so, perhaps choosing a font
> with better coverage will make the situation better for you?

It would not eliminate the problem though. I’m editing a file with new emojis in Unicode 16 (released recently in September) and the emojis are glyphless currently. I experience unbearable delays whenever such glyphs are visible.

Based on the profiling, my guess is that CTFontDescriptorCreateMatchingFontDescriptors is doing a linear search internally (it probably didn’t just pick the specified by the font family?), so macfont_list is accidentally O(n^2).  This (if true) should explain why it’s so slow.


[-- Attachment #2: Type: text/html, Size: 20271 bytes --]