GNU bug report logs -
#71454
30.0.50; Performance issues with font selection
Previous Next
Full log
View this message in rfc822 format
[Message part 1 (text/plain, inline)]
> On Sep 27, 2024, at 08:32, Eli Zaretskii <eliz <at> 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.
[Message part 2 (text/html, inline)]
This bug report was last modified 248 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.