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

[Moses]

On Sun, Jul 15, 2018 at 2:41 PM Eli Zaretskii <eliz@gnu.org> wrote:
>
> > From: Moses <moses.mason@gmail.com>
> > Date: Sun, 15 Jul 2018 05:50:26 +0000
> > Cc: 32159@debbugs.gnu.org
> >
> > 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.
>
> Do some of the characters in HELLO display as boxes with hex code
> inside them, and if so, do you see slow-down when Emacs is about to
> display those characters?  If the answer to both question is YES, I
> can suggest a customization to try that might help you avoid the
> slowdown (assuming you don't need to be able to display characters
> from those scripts), but please tell what characters are involved in
> this.

Nope...all characters in the HELLO file can be display correctly
without a problem, the lagging issue only appears while opening the
file. Once it already opened, there is no more slowdown.

> > Other editor does not have the similar issue.
>
> AFAIK, no other editor supports such a large variety of fonts.

I mean other editors do not have slowdown problem while opening such a
relatively small file. They are not as mighty as Emacs of course.
That's why I am using Emacs to process editing :)


> > 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?
>
> I don't think that Registry setting is relevant to the issue at hand.
> Emacs looks for fonts based on its internal database of features
> required by each script.