unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: "Kai Ma" <justksqsf@gmail.com>, "Alan Third" <alan@idiocy.org>,
	"Po Lu" <luangruo@yahoo.com>,
	"Gerd Möllmann" <gerd.moellmann@gmail.com>
Cc: 71454@debbugs.gnu.org
Subject: bug#71454: 30.0.50; Performance issues with font selection
Date: Fri, 27 Sep 2024 09:32:50 +0300	[thread overview]
Message-ID: <86y13d8v3h.fsf@gnu.org> (raw)
In-Reply-To: <22612F93-FC37-48E8-8137-E9FF6F5B3A0D@gmail.com> (message from Kai Ma on Fri, 27 Sep 2024 00:42:04 +0200)

> From: Kai Ma <justksqsf@gmail.com>
> Date: Fri, 27 Sep 2024 00:42:04 +0200
> 
> I got back to this problem today and have some initial ideas.
> 
> I did some profiling and the profiler clearly shows that most CPU time was in macfont_list and CTFontDescriptorCreateMatchingFontDescriptors. (screenshot attached below) So yes, it’s a Mac-only problem.
> 
> macfont_list will call CTFontDescriptorCreateMatchingFontDescriptors for n times, where n is the number of installed fonts. It seems CTFontDescriptorCreateMatchingFontDescriptors is very expensive, and we should minimize the use of it.
> 
> I did a quick proof-of-concept patch (attached) that removes the outer loop (utilizing CTFontDescriptorCreateMatchingFontDescriptors itself to search for fonts). And now I no longer experience long delays. It’s not complete as I haven’t adapted & incorporated mac_font_create_preferred_family_for_attributes yet.
> 
> I don’t see noticeable font differences after the change on the files I’m working on. I would like to gather some feedback from the more experienced on whether this is a promising solution or not. If it is, I will refine it into a formal patch.

Thanks.  I'm adding a few people in the hope that they could comment
on the patch, or maybe try it and provide feedback.

> > 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)?

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?





  parent reply	other threads:[~2024-09-27  6:32 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-06-09 18:56 bug#71454: 30.0.50; Performance issues with font selection Kai Ma
2024-06-09 22:10 ` Jeremy Bryant via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-06-09 22:17   ` Kai Ma
2024-06-09 22:34     ` Jeremy Bryant via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-06-10  2:14       ` Kai Ma
2024-06-10 12:04         ` Eli Zaretskii
2024-06-09 23:10     ` Jim Porter
2024-06-10  2:18       ` Kai Ma
2024-06-10 11:53         ` Eli Zaretskii
2024-06-10 16:31           ` Jim Porter
2024-06-10 17:35             ` Eli Zaretskii
2024-06-10 11:55     ` Eli Zaretskii
2024-06-10 12:35       ` Kai Ma
2024-06-10 12:59         ` Eli Zaretskii
2024-06-10 16:42           ` Gerd Möllmann
2024-06-10 17:36             ` Kai Ma
2024-06-10 18:05               ` Gerd Möllmann
2024-06-10 11:58 ` Eli Zaretskii
2024-06-10 12:34   ` Kai Ma
2024-06-10 13:03     ` Eli Zaretskii
     [not found] ` <22612F93-FC37-48E8-8137-E9FF6F5B3A0D@gmail.com>
2024-09-27  6:32   ` Eli Zaretskii [this message]
2024-09-27  7:51     ` Kai Ma
2024-09-27 10:29       ` Eli Zaretskii
2024-09-28  3:36     ` Gerd Möllmann

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=86y13d8v3h.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=71454@debbugs.gnu.org \
    --cc=alan@idiocy.org \
    --cc=gerd.moellmann@gmail.com \
    --cc=justksqsf@gmail.com \
    --cc=luangruo@yahoo.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).