http://bugzilla.opensuse.org/show_bug.cgi?id=1197544 http://bugzilla.opensuse.org/show_bug.cgi?id=1197544#c6 --- Comment #6 from Jan Engelhardt <jengelh@inai.de> --- 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. -- You are receiving this mail because: You are on the CC list for the bug.