[Top][All Lists]

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

Re: Rendering performace vs. line-spacing

From: Herman, Geza
Subject: Re: Rendering performace vs. line-spacing
Date: Fri, 8 Jan 2021 14:46:10 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0

On 2021-01-08 13:22, Eli Zaretskii wrote:
From: Herman, Géza <geza.herman@gmail.com>
Date: Fri, 8 Jan 2021 12:34:53 +0100

I noticed that emacs's performance can depend on the font. For example,
Consolas has a much worse performance (scrolling is sluggish) than
BitStream Mono. I profiled emacs, and the main difference is
"draw_glyphs". When emacs is slow (using consolas), this function takes
50-60% of CPU time (measured by "perf record -g"). When emacs is fast
(using BitStream), this function takes only ~2-3%.

I played with my font's ascent and descent settings to have more line on
the screen (as emacs doesn't support negative line-spacing). Originally,
"draw_glyphs" takes 2-3% with my font. But if I decrease the height of
the font by modifying ascent/descent, then the same thing happens:
draw_glyphs takes 50-60% CPU time. If I set line-spacing to 2,
draw_glyphs become normal, 2-3% CPU time.

When screen lines can overlap, we have code to handle that, and it
indeed could slow down redisplay.  However, you are saying that you
_decrease_ ascent/descent, and I'm not sure I understand how could
that cause overlaps?
In fontforge, I made these values smaller. So, this causes that emacs will display the font as if line-spacing were negative. So, lines start to overlap, because the actual height of the glyph doesn't change, but the vertical spacing between them is smaller.

In any case, I suggest to profile the code with perf, and see which
parts of the display code (below draw_glyphs) take those cycles with
the problematic font(s).  Then we will see which part is the culprit,
and could take it from there.
I did a perf record with emacs -Q, the results are better than my full configuration, but the difference is still there (now I see that there is a function which has a telling name about overlap: gui_fix_overlapping_area):

- 27.75% draw_glyphs
      - 18.80% gui_fix_overlapping_area
         - 18.63% update_window
            - redisplay_internal
               - 10.33% read_char
               - 8.09% read_key_sequence
         + 0.17% draw_phys_cursor_glyph
      - 8.86% gui_write_glyphs
         - 7.93% update_window_line
            - redisplay_internal
               + 4.51% read_char
               + 3.33% read_key_sequence
         + 0.93% update_window

With larger line-spacing, this function takes 0.86%:

      - 0.76% gui_write_glyphs
         - redisplay_internal
            - 0.63% read_char
        0.10% draw_phys_cursor_glyph

But the overall effect is that with the overlapping setting, scrolling is sluggish. If there's no overlap, scrolling is smooth, so I think that actually there's a larger difference than the additional 25% CPU usage.

It's not a big deal of course (otherwise emacs works OK, it's just the scrolling which is not smooth).

reply via email to

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