GNU bug report logs -
#78766
100-4000x redisplay slowdown with vscroll>0 and make-cursor-line-fully-visible=t
Previous Next
Full log
View this message in rfc822 format
[Message part 1 (text/plain, inline)]
Users of ultra-scroll noticed significant slowdowns in some situations. We traced it back to the combination of:
- vscroll > 0 (ultra-scroll, like pixel-scroll-precision, uses vscroll for its scrolling implementation)
- make-cursor-line-fully-visible=t
Note that pixel-scroll-precision disables make-cursor-line-fully-visible, but this leads to partially visible lines causing problems in various other situations (e.g. comint-scroll-show-maximum-output). So disabling isn't ideal.
A simple test (validated in Emacs 30 with NS and mac builds) is attached. Evaluate the buffer and it will enable make-cursor-line-fully-visible, visit simple.el, then time moving forward to the end of a line with and without non-zero vscroll.
This is painfully slow with make-cursor-line-fully-visible=t. The reported slowdown for simple motion commands like forward-char is 100-4000x.
I've profiled the slow case, see attached for the important parts. As is clear, of the ~8s it took to move to the end of the line (twice), get_next_display_element and set_iterator_to_next are the main culprits (arrived at separately via try_window and partial_line_height) with gui_produce_glyphs contributing.
Notably, this slowdown attends all frames and windows showing the buffer, and can leak into some other windows like the minibuffer, when a buffer in some window is in this state.
[test_vscroll_induced_lag.el (application/octet-stream, attachment)]
[vscroll_lag_profile.txt (text/plain, attachment)]
[Message part 4 (text/plain, inline)]
[1] In this instance. This can vary with window size, sometimes 2s or more per forward-char is possible.
This bug report was last modified today.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.