Comment # 6 on bug 1197544 from Jan Engelhardt

Some thoughts:

I have seen something like that before, even in X11. It is not so much a
scrolling problem as it is a latency issue.

For example, I have my keyboard repeat rate set to 40cps, i.e. one character
every 25000 ���sec. I can reproduce the "scrolling issue" in xterm with such a
prompt:

PS1='\w$(usleep 22000)> '

which means there is a total latency of almost 3000���s. xterm has to process the
ENTER key input, bash has to parse the empty command, then parse PS1 to show
the next prompt, spin up a subprocess, that subprocess has to load and finish,
and then the prompt text (TTF!) needs to be rendered, etc. Both bash and {the
dynamic loader which runs as part of /usr/bin/usleep} have been getting fatter
over the past 20 years in general. If I do the same in dash, I need to use
23000 to get a similar effect, which means dash is about 1ms more effective in
parsing etc.

Other aggravating factors:

* openSUSE's default PS1 contains $(spwd), which adds another 2.5ms of latency
in my testing

* libvte-based terminals have had really bad latency characteristics of their
own, https://lwn.net/Articles/751763/ . That article is from 2018, I don't know
how things look in 2022. Also, I envision that the article is measuring quite
differently than I am. In my adhoc test, libvte(on X11) latency is only about
3.5ms worse than xterm.