Re: Rendering performace vs. line-spacing

[Herman, Geza]

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
              update_window_tree
              update_frame
            - redisplay_internal
               - 10.33% read_char
                    read_key_sequence
               - 8.09% read_key_sequence
                    command_loop_1
         + 0.17% draw_phys_cursor_glyph
      - 8.86% gui_write_glyphs
         - 7.93% update_window_line
              update_window
              update_window_tree
              update_frame
            - 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.86%
      - 0.76% gui_write_glyphs
           update_window_line
           update_window
           update_window_tree
           update_frame
         - redisplay_internal
            - 0.63% read_char
                 read_key_sequence
        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).