Subject: bug#78766: closed (Re: bug#78766: 100-4000x redisplay slowdown with vscroll>0 and make-cursor-line-fully-visible=t)

From: [email-masked] (GNU bug Tracking System)
Date: Tue, 17 Jun 2025 13:03:02 +0000

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 [email-masked].

-- 
78766: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=78766
GNU Bug Tracking System
Contact [email-masked] with problems

Subject: Re: bug#78766: 100-4000x redisplay slowdown with vscroll>0 and make-cursor-line-fully-visible=t
From: Eli Zaretskii <[email-masked]>
To: JD Smith <[email-masked]>
Cc: [email-masked]
Date: Tue, 17 Jun 2025 16:02:15 +0300
List-Id: <debbugs-submit.debbugs.gnu.org>

> From: JD Smith <[email-masked]>
> Date: Tue, 17 Jun 2025 08:41:03 -0400
> Cc: [email-masked]
> 
>  On Jun 17, 2025, at 7:30 AM, Eli Zaretskii <[email-masked]> 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.

Subject: 100-4000x redisplay slowdown with vscroll>0 and make-cursor-line-fully-visible=t
From: JD Smith <[email-masked]>
To: [email-masked]
Date: Wed, 11 Jun 2025 19:08:01 -0400
List-Id: <debbugs-submit.debbugs.gnu.org>

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.

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