GNU bug report logs -
#78766
100-4000x redisplay slowdown with vscroll>0 and make-cursor-line-fully-visible=t
Previous Next
Full log
Message #17 received at 78766 <at> debbugs.gnu.org (full text, mbox):
> From: JD Smith <jdtsmith <at> gmail.com>
> 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.
This bug report was last modified 1 day ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.