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

From: help-debbugs <at> gnu.org (GNU bug Tracking System)
To: JD Smith <jdtsmith <at> gmail.com>
Subject: bug#78766: closed (Re: bug#78766: 100-4000x redisplay slowdown
 with vscroll>0 and make-cursor-line-fully-visible=t)
Date: Tue, 17 Jun 2025 13:03:02 +0000

[Message part 1 (text/plain, inline)]

Your bug report

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

which was filed against the emacs package, has been closed.

The explanation is attached below, along with your original report.
If you require more details, please reply to 78766 <at> debbugs.gnu.org.

-- 
78766: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=78766
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems

[Message part 2 (message/rfc822, inline)]

From: Eli Zaretskii <eliz <at> gnu.org>
To: JD Smith <jdtsmith <at> gmail.com>
Cc: 78766-done <at> debbugs.gnu.org
Subject: Re: bug#78766: 100-4000x redisplay slowdown with vscroll>0 and
 make-cursor-line-fully-visible=t
Date: Tue, 17 Jun 2025 16:02:15 +0300

> From: JD Smith <jdtsmith <at> gmail.com>
> Date: Tue, 17 Jun 2025 08:41:03 -0400
> Cc: 78766 <at> debbugs.gnu.org
> 
>  On Jun 17, 2025, at 7:30 AM, Eli Zaretskii <eliz <at> gnu.org> wrote:
> 
>  Are you saying that the patch you sent... Fixes the problem for you and doesn't have any adverse
>  effects, so I
> 
>  can install it?
> 
> Yes, exactly.  

Thanks, now installed on master, and closing the bug.

[Message part 3 (message/rfc822, inline)]

From: JD Smith <jdtsmith <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 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 4 (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 7 (text/plain, inline)]

[1] In this instance.  This can vary with window size, sometimes 2s or more per forward-char is possible.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.