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

From: Eli Zaretskii <[email-masked]>
Date: Fri, 13 Jun 2025 18:16:22 +0300

> From: JD Smith <[email-masked]>
> Date: Fri, 13 Jun 2025 10:07:05 -0400
> 
> Quick followup.  I was able to instrument the single function `set_iterator_to_next' to track total call count and distribution of call times of this core function.  Since the instrumentation slowed the test down so much, I profiled moving (forward-char) by just 3 chars with redisplay in a partially visible top line, using the slow setting of make-cursor-line-fully-visible=t.  
> 
> The total call count per character moved in the slow case is enormous: >800K.

Thanks, but this doesn't really add any useful info.
set_iterator_to_next is too low-level to explain what's going on.  It
is expected that it will be called many times, but the question is
why?  And the answer to that is at higher levels, at the level of the
functions called by redisplay_window.

IOW, if we call set_iterator_to_next so many times, we either (a)
redraw the entire window many times, or (b) redraw some small subset
of the window's lines even more times.  Which one(s) of these actually
happen and why is the interesting question.

And you still haven't explained to me what you want Emacs to do when
you set vscroll > 0 (which necessarily makes the top-most screen line
partially-visible) and also set make-cursor-line-fully-visible = t.
These two contradict one another, so you basically ask Emacs to square
the circle.

You also haven't explained why using the solution of
pixel-scroll-precision-mode is not good for your mode.