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

Previous Next

Full log

Message #29 received at 78766 <at> debbugs.gnu.org (full text, mbox):

From: JD Smith <jdtsmith <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 78766 <at> debbugs.gnu.org
Subject: Re: bug#78766: 100-4000x redisplay slowdown with vscroll>0 and
 make-cursor-line-fully-visible=t
Date: Sun, 15 Jun 2025 12:37:03 -0400

> On Jun 14, 2025, at 9:14 AM, Eli Zaretskii <eliz <at> gnu.org> wrote:
> 
> I've now looked at this.  It's like I guessed: this case of having the
> cursor in the first visible line that is only partially visible is not
> supported, and the code just loops until we forcibly stop that:

Good find, thanks for looking at this.  I tested the patch.  While it eliminated the slowdown, it led to other redisplay artifacts when point is on a partially visible top line, such as duplicated half overlapping mode-lines when invoking M-x.

But perhaps you did not intend to always return SCROLLING_SUCCESS here?

+   if (MATRIX_ROW_PARTIALLY_VISIBLE_AT_TOP_P
+ (w, MATRIX_ROW (w->desired_matrix, w->cursor.vpos)))
+     rc = SCROLLING_FAILED;
+   else
+     goto too_near_end;
}
 rc = SCROLLING_SUCCESS;

If I modify that to return FAILED immediately, ala:

 if (MATRIX_ROW_PARTIALLY_VISIBLE_AT_TOP_P
(w, MATRIX_ROW (w->desired_matrix, w->cursor.vpos)))
   return SCROLLING_FAILED;
 else
   goto too_near_end;
}
      rc = SCROLLING_SUCCESS;

I get no artifacts, and it seems to do what I'd expect — if you try to move point onto a partially visible top row, the window is recentered according to scroll-conservatively.

Seems to work normally with line-move and tall images.  I will run with it for a while to see if anything else appears.

Thanks again.

Previous Next

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