* Rendering performace vs. line-spacing @ 2021-01-08 11:34 Herman, Géza 2021-01-08 12:22 ` Eli Zaretskii 0 siblings, 1 reply; 7+ messages in thread From: Herman, Géza @ 2021-01-08 11:34 UTC (permalink / raw) To: emacs-devel Hi all, 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. (I'm using a master build from yesterday) Any ideas why this happens? Maybe this happens because lines may overlap and some caching mechanism gets disabled? Thanks, Geza ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Rendering performace vs. line-spacing 2021-01-08 11:34 Rendering performace vs. line-spacing Herman, Géza @ 2021-01-08 12:22 ` Eli Zaretskii 2021-01-08 13:46 ` Herman, Geza 0 siblings, 1 reply; 7+ messages in thread From: Eli Zaretskii @ 2021-01-08 12:22 UTC (permalink / raw) To: geza.herman; +Cc: emacs-devel > 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. > > (I'm using a master build from yesterday) > > Any ideas why this happens? Maybe this happens because lines may overlap > and some caching mechanism gets disabled? 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 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. ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Rendering performace vs. line-spacing 2021-01-08 12:22 ` Eli Zaretskii @ 2021-01-08 13:46 ` Herman, Geza 2021-01-08 14:35 ` Eli Zaretskii 0 siblings, 1 reply; 7+ messages in thread From: Herman, Geza @ 2021-01-08 13:46 UTC (permalink / raw) Cc: emacs-devel 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). ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Rendering performace vs. line-spacing 2021-01-08 13:46 ` Herman, Geza @ 2021-01-08 14:35 ` Eli Zaretskii 2021-01-08 15:38 ` Herman, Geza 0 siblings, 1 reply; 7+ messages in thread From: Eli Zaretskii @ 2021-01-08 14:35 UTC (permalink / raw) To: Herman, Geza; +Cc: emacs-devel > Cc: emacs-devel@gnu.org > From: "Herman, Geza" <geza.herman@gmail.com> > Date: Fri, 8 Jan 2021 14:46:10 +0100 > > - 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. If screen lines overlap with the offending font, then the difference could be justified, because redrawing one screen line would require redrawing the two adjacent screen lines. I'm a bit surprised by the large performance hit, though, so maybe it's worth looking at the code which gets run in the slow case, to see maybe some unnecessary work we are doing in that case. Do you have very wide windows, per chance? Does the problem becomes smaller if you make your frames and windows narrower? ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Rendering performace vs. line-spacing 2021-01-08 14:35 ` Eli Zaretskii @ 2021-01-08 15:38 ` Herman, Geza 2021-01-08 15:46 ` Eli Zaretskii 0 siblings, 1 reply; 7+ messages in thread From: Herman, Geza @ 2021-01-08 15:38 UTC (permalink / raw) To: Eli Zaretskii; +Cc: emacs-devel On 2021-01-08 15:35, Eli Zaretskii wrote: > If screen lines overlap with the offending font, then the difference > could be justified, because redrawing one screen line would require > redrawing the two adjacent screen lines. I'm a bit surprised by the > large performance hit, though, so maybe it's worth looking at the code > which gets run in the slow case, to see maybe some unnecessary work we > are doing in that case. > > Do you have very wide windows, per chance? Does the problem becomes > smaller if you make your frames and windows narrower? Yes, my full screen emacs has a width of ~270. Sometimes I use this as a full screen window, sometimes I split it into two with split-window-horizontally. And yes, the problem becomes smaller if I make the window narrower, or if the screen contains less characters. This problem is most visible at a particular part of my code which contains a larger table, with long lines (~160). I disabled redrawing caused by overlapping by commenting out the line which sets the "row->overlapping_p" flag (xdisp.c:21752), and the problem is gone away. But my fonts are clipped (not a surprise). But, it fixed the consolas case as well, and I don't see any clipping with this font. Maybe overlapping detection is too strict (I mean, emacs considers cases overlapping which are close to overlapping, but they aren't)? Or maybe I just don't notice the clipping. ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Rendering performace vs. line-spacing 2021-01-08 15:38 ` Herman, Geza @ 2021-01-08 15:46 ` Eli Zaretskii 2021-01-08 16:04 ` Herman, Geza 0 siblings, 1 reply; 7+ messages in thread From: Eli Zaretskii @ 2021-01-08 15:46 UTC (permalink / raw) To: Herman, Geza; +Cc: emacs-devel > Cc: emacs-devel@gnu.org > From: "Herman, Geza" <geza.herman@gmail.com> > Date: Fri, 8 Jan 2021 16:38:10 +0100 > > I disabled redrawing caused by overlapping by commenting out the line > which sets the "row->overlapping_p" flag (xdisp.c:21752), and the > problem is gone away. But my fonts are clipped (not a surprise). But, it > fixed the consolas case as well, and I don't see any clipping with this > font. Maybe overlapping detection is too strict (I mean, emacs considers > cases overlapping which are close to overlapping, but they aren't)? Or > maybe I just don't notice the clipping. It could be that in the case of Consolas the overlapping doesn't actually happen, but some metrics we get from the font tell us they are. Or maybe they do happen, but only when very few characters from the font are used. Or maybe this also depends on the font backend, like whether you build with or without Cairo. This calls for some font expert(s) to study the Consolas case and see why the problem happens there. Perhaps we could speed up at least that case, I don't know. ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Rendering performace vs. line-spacing 2021-01-08 15:46 ` Eli Zaretskii @ 2021-01-08 16:04 ` Herman, Geza 0 siblings, 0 replies; 7+ messages in thread From: Herman, Geza @ 2021-01-08 16:04 UTC (permalink / raw) To: Eli Zaretskii; +Cc: emacs-devel On 2021-01-08 16:46, Eli Zaretskii wrote: >> Cc: emacs-devel@gnu.org >> From: "Herman, Geza" <geza.herman@gmail.com> >> Date: Fri, 8 Jan 2021 16:38:10 +0100 >> >> I disabled redrawing caused by overlapping by commenting out the line >> which sets the "row->overlapping_p" flag (xdisp.c:21752), and the >> problem is gone away. But my fonts are clipped (not a surprise). But, it >> fixed the consolas case as well, and I don't see any clipping with this >> font. Maybe overlapping detection is too strict (I mean, emacs considers >> cases overlapping which are close to overlapping, but they aren't)? Or >> maybe I just don't notice the clipping. > It could be that in the case of Consolas the overlapping doesn't > actually happen, but some metrics we get from the font tell us they > are. Or maybe they do happen, but only when very few characters from > the font are used. Or maybe this also depends on the font backend, > like whether you build with or without Cairo. > > This calls for some font expert(s) to study the Consolas case and see > why the problem happens there. Perhaps we could speed up at least > that case, I don't know. Okay, thanks for the help! I adjusted my font's ascent/descent, and now I don't see any clipping with this font either (for the record, I'm using Cairo). If I have the time, I may have a look at this part of emacs's code and try to understand what's going on exactly. ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2021-01-08 16:04 UTC | newest] Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2021-01-08 11:34 Rendering performace vs. line-spacing Herman, Géza 2021-01-08 12:22 ` Eli Zaretskii 2021-01-08 13:46 ` Herman, Geza 2021-01-08 14:35 ` Eli Zaretskii 2021-01-08 15:38 ` Herman, Geza 2021-01-08 15:46 ` Eli Zaretskii 2021-01-08 16:04 ` Herman, Geza
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).