bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#21028: Slow font rendering in emacs


From: Ralf Jung
Subject: bug#21028: Slow font rendering in emacs
Date: Mon, 13 Mar 2017 19:12:10 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0

Hi Eli,

Wow, that was a quick reply!

>> From: Ralf Jung <post@ralfj.de>
>> Date: Mon, 13 Mar 2017 16:54:01 +0100
>>
>> I think I ran into the issue described here as well:  If I am not
>> careful with the way I configure my fonts, emacs becomes pretty slow at
>> rendering them.  With my old laptop, actually merely navigating the
>> cursor large files (like
>> <https://gitlab.mpi-sws.org/robbertkrebbers/coq-stdpp/raw/master/theories/list.v>)
>> already was noticeably luggish.
> 
> I don't see any sluggish-ness in "emacs -Q" here, FWIW.
> 
> Do you have any measurements that would show the slowdown in numbers?

I know very little about emacs, so I wouldn't know how to make any
measurements.  Also, I don't have access to my old machine any more.
I may try adapting some of the timing scripts that you and Clément were
using, and see if I can quantify anything.

> Also, what is your value of system-configuration-options and
> system-configuration-features?  And which version of Emacs is that?

Sorry, I have no idea how to read those variables and a quick google
search was not very fruitful.
This is emacs 24.5+1-8 as packaged by Debian.

> What happens if you don't make any of the above customizations?

Emacs is fine in terms of speed, but it uses the wrong font for
characters not supported by Fira Sans Mono.
For example, for ∃ it picks "STIX", which seems to have broken metrics
because the character is higher than all the others (it extends ~20%
below the bottom bar, breaking the height of the entire line).  For ∗ it
picks DejaVu Math TeX Gyre, which is too wide.  For ⋅ it picks EB
Garamond SC which is way too small.

Opening the same file on the same system in Kate or gedit results in the
expected rendering -- all characters fit the grid; unfortunately I don't
know how to figure out which fonts they picked for what.  I did no
configuration whatsoever to achieve this, besides installing Fira Sans.
This was the case even before I installed Symbola.

> Also, do you have the Symbola font installed?  If not, can you install
> it and see if that makes things better?

I do have it installed.  emacs doesn't seem to pick it per default.
The reason I have it installed is that some characters (like ∖) are
supported neither by Fira Sans Mono nor by DejaVu Mono, so then I made
it fall back to Symbola.  These are very few rarely used characters, so
the fact that the widths don't match up is much less of a problem.  My
full configuration is:


;; Fonts
(dolist (ft (fontset-list))
  ; Main font
  (set-fontset-font ft 'unicode (font-spec :name "Monospace" :size 11.0))
  ; Fallback font
  ; Appending to the 'unicode list makes emacs unbearably slow.
  ;(set-fontset-font ft 'unicode (font-spec :name "DejaVu Sans Mono"
:size 11.0) nil 'append)
  (set-fontset-font ft nil (font-spec :name "DejaVu Sans Mono" :size 11.0))
)
; Fallback-fallback font
; If we 'append this to all fontsets, it picks Symbola even for some
cases where DejaVu could
; be used. Adding it only to the "t" table makes it Do The Right Thing (TM).
(set-fontset-font t nil (font-spec :name "Symbola" :size 11.0))

And just in case you wonder -- no, I have no idea what I am doing here.
I arrived at that configuration after several hours of random, fairly
unguided modifications to it until all my test characters picked the
font I wanted:
→  Fira Sans Mono (even though DejaVu can also do it, but the arrow in
   Fira looks much better IMHO)
∃  DejaVu Mono (not supported by Fira, it seems)
∀  DejaVu Mono (not supported by Fira, it seems)
∗  DejaVu Mono (not supported by Fira, it seems)
⋅  DejaVu Mono (not supported by Fira, it seems; the one in Symbola
   is *tiny*)
∖  Symbola (for lack of an alternative)

I shortened the configuration in my first mail because I was focusing on
the performance issue.  While I do consider it a bug that emacs picks
the wrong fonts per default, shouldn't emacs be reasonably fast to use
even if I do some manual configuration?  The bug at hand IMHO wouldn't
be fixed if the default emacs configuration was making better choices
for the fonts (though of course I wouldn't be affected by it anymore;
but then, neither am I now since I found a way to work around it).

>> Configuring fonts in emacs to get proper unicode rendering is already
>> fairly difficult
> 
> Actually, the default fontset is supposed to "just work", so I'd be
> interested to hear why you needed to customize that.

> I'm trying.  But it's hard, since for now I cannot even reproduce it.

I acknowledge that it'd be much easier if you could reproduce the
problem.  That said, there's a patch that Clément said works.  Honestly
I am a little puzzled why you are so hesitant to apply a patch that you
wrote, and that reportedly fixes the problem.  Do you expect that patch
to have negative side-effects?  Of course this is ultimately up to you,
I am just expressing my surprise here.

Kind regards,
Ralf





reply via email to

[Prev in Thread] Current Thread [Next in Thread]