bug#21028: Slow font rendering in emacs

[Ralf Jung]

Hi,

> Could be, I don't know.  Once again, if the defaults, without any font
> customizations, are somehow not good for you, please report the
> details in a bug report.

All right, I put that on my ToDo list.

>> 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.

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

Kind regards,
Ralf