Package: xterm
Version: 210-3
Severity: minor
I've noticed that there is a considerable slowdown in scrolling speed
when lines contain ansi-color codes that change the background (!)
colour.
This slowdown is hardly noticeable on a reasonably fast machine, but
on my trusty old toshiba libretto (only 266 Mhz, but I'll never part
with it) listing a directory with 200 files with ls --color=yes is
unbearably slow.
This must have crept in a few updates ago, I can't remember scrolling
being that slow on the laptop before. It's not fixed in 210-3.1
(tested on the laptop, uses same distribution and software, but
neomagic display hardware) and not in upstream (220) either.
The following loop in a bash tests that behaviour:
bogomips=`grep bogomips /proc/cpuinfo|tail -1|cut -f2 -d:|cut -f1 -d.`; wallclock=`date +%s`;i=0; while [ $i -lt $bogomips ]; do echo -e "\033[47m$i\033[00m"; i=$(($i + 1)); done; echo $((`date +%s` - $wallclock)) seconds
Outputs numbers up to $bogomips with white background. Will take about
10 seconds on my athlon 550 at home and the machines at work (intel
2800 mhz), and about 55 seconds on my laptop. I assume something
causes additional sluggishness on the laptop (maybe the display
driver? There's an old bug at
https://bugs.freedesktop.org/show_bug.cgi?id=1877 which might be
related).
The slowdown only happens when the background colour is changed, so if
you change the first escape sequence in the echo string to e.g.
"\033[31m" (red foreground) the whole loop takes about 1 second.
Also there is no slowdown in rxvt, on any machine.
I think this should probably be forwarded to upstream but I'd like it
to be in the debian BTS nonetheless.
Finally I manage to hit a bug that is actually reproducible! :)
Kind regards
Friedel