GNU bug report logs - #78766
100-4000x redisplay slowdown with vscroll>0 and make-cursor-line-fully-visible=t

Previous Next

Package: emacs;

Reported by: JD Smith <jdtsmith <at> gmail.com>

Date: Wed, 11 Jun 2025 23:09:02 UTC

Severity: normal

Done: Eli Zaretskii <eliz <at> gnu.org>

Full log


View this message in rfc822 format

From: JD Smith <jdtsmith <at> gmail.com>
To: 78766 <at> debbugs.gnu.org
Subject: bug#78766: 100-4000x redisplay slowdown with vscroll>0 and make-cursor-line-fully-visible=t
Date: Wed, 11 Jun 2025 19:08:01 -0400
[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.