GNU bug report logs - #32159
26.1; inhibit-compacting-font-caches does not fix all fonts lagging issue

Previous Next

Full log

Message #11 received at 32159 <at> debbugs.gnu.org (full text, mbox):

From: Moses <moses.mason <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 32159 <at> debbugs.gnu.org
Subject: Re: bug#32159: 26.1; inhibit-compacting-font-caches does not fix all
 fonts lagging issue
Date: Sun, 15 Jul 2018 05:50:26 +0000

You are right. I got 5906 installed fonts returned from (length
(x-list-fonts "*")). However, this still a problem, which is really
annoying when editing files that contain more than one language. Other
editor does not have the similar issue. I am not an expert, but as far
as I know, the font fallback link is already stored in the register
under key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows
NT\CurrentVersion\FontLink\SystemLink, why Emacs still needs to search
fonts multiple times?


On Sun, Jul 15, 2018 at 2:39 AM Eli Zaretskii <eliz <at> gnu.org> wrote:
>
> > From: Moses <moses.mason <at> gmail.com>
> > Date: Sun, 15 Jul 2018 00:02:13 +0000
> >
> > For bug#24938, I have to set inhibit-compacting-font-caches to non-nil
> > [0] to fix the lagging issue. It fixes almost but not all the
> > problems. Lagging reappears when I opening a multi languages file
> > (e.g. M-x view-hello-file),  Emacs could become very very slow until
> > the file is completely opened.
>
> That lagging might have a valid reason: how many fonts do you have
> installed?  What does (length (x-list-fonts "*")) return?
>
> If you have many fonts, Emacs will search them all to find a suitable
> one, and if some characters in HELLO don't have fonts, it will search
> them several times.  That might take time.  If the lagging disappears
> once you display the entire file, that is most probably the reason.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.