Comment # 7 on bug 1197544 from B

(In reply to Jan Engelhardt from comment #6)
> 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.

thanks for your input, any idea on how to fix this? Why is it only affecting
Wayland and not X11?
I'm esp. wondering because, not all of my machines are affected and they are
all running TW.