[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#21028: Slow font rendering in emacs
From: |
Eli Zaretskii |
Subject: |
bug#21028: Slow font rendering in emacs |
Date: |
Sat, 22 Apr 2017 16:40:50 +0300 |
> Cc: 21028@debbugs.gnu.org
> From: Ralf Jung <post@ralfj.de>
> Date: Sat, 22 Apr 2017 10:54:56 +0200
>
> >> Of course this is just an excerpt of the characters we use. From all I
> >> can tell, the general rule is "if the character is supported by Fira,
> >> use that font; else of it is supported by DejaVu, use that font; else do
> >> <no idea what it does>"
> >
> > As you have seen, this does work as you want, but it's slow. We are
> > talking about getting you the same functionality, but faster. That
> > comes for a price of more accurate fontset setup.
>
> Well, we also have a patch fixing that slowness, so it doesn't seem to
> be an inherent problem, just some implementation artifact.
That patch has been applied, in case you weren't tracking this bug.
> >> I don't think the font is to blame here. After all, other applications
> >> manage to deal with exactly the same fonts just fine.
> >> Unfortunately, I don't know *how* everybody else is selecting fonts, I
> >> only know they do a better job at it than emacs, and they have no
> >> problem dealing with fonts that only partially support some blocks.
> >> Probably fontconfig is doing most of the work here, but I am really just
> >> guessing.
> >
> > Most other applications don't deal with multi-lingual text, so their
> > job is easier. Emacs attempts to solve a harder problem here.
>
> What exactly does this mean? I sure would expect all these editors to
> correctly display text that mixes Latin, Greek, Cyrillic and Japanese
> characters.
Most editors assume each file will only ever include text in a single
language. Emacs explicitly tries to do better when several languages
and scripts are mixed in the same file/buffer.
Emacs also has some rules for selecting fonts based on cultural
preferences, so it could use different fonts for the same Unicode
codepoints in different locales.
> I believe they can handle this, but have to admit I did not try that
> (mostly for lack of a personal use-case). Is there an example that
> can be used to test this?
I'd begin with the HELLO file.