xterm vs. urxvt scrolling speed

[xi]

hi, i just wondered why xterm scrolling is so much slower than urxvt.

i did some "benchmark":

XTERM time ls --color=auto -al /usr/bin

Code: Select all

real    0m11.580s
user    0m0.075s
sys     0m0.057s

XTERM time ls --color=auto -al /usr/bin > /dev/null

Code: Select all

real    0m0.108s
user    0m0.065s
sys     0m0.024s

(this tells me cpu is really used for displaying)

URXVT time ls --color=auto -al /usr/bin

Code: Select all

real	0m2.874s
user	0m0.069s
sys	0m0.100s

Xdefaults settings:

Code: Select all

Xcursor.theme: whiteglass
XTerm*charClass:        33:48,37:48,45-47:48,64:48
XTerm*cutNewline:       False
XTerm*cutToBeginningOfLine:     False
XTerm*scrollTtyOutput:        false
*customization: -color
XTerm*faceName:   xft:Bitstream Vera Sans Mono
XTerm*faceSize:     16
XTerm*scrollBar:    false
XTerm*reverseVideo: true
#XTerm*foreground: lightgrey
XTerm*loginShell: true
XTerm*saveLines: 10000
XTerm*cursorColor:  yellow
XTerm*utf8: 1 
XTerm*jumpScroll:               true
XTerm*multiScroll:              true
XTerm*popOnBell:        true
urxvt.font: xft:Bitstream Vera Sans Mono:size=16
urxvt.loginShell: true
urxvt.saveLines: 10000
urxvt.reverseVideo: true
urxvt*scrollBar:      false
urxvt*scrollTtyOutput:      false 
urxvt*scrollWithBuffer:      false 
urxvt*scrollTtkKeypress:   false

[frostschutz]

Using the same benchmark:

Code: Select all

~ $ time xterm -e ls --color=auto -al /usr/bin/

real    0m1.658s
user    0m0.925s
sys     0m0.075s
~ $ time urxvt -e ls --color=auto -al /usr/bin/

real    0m0.306s
user    0m0.141s
sys     0m0.039s
~ $

However, note that 'ls --color=auto -al /usr/bin/' is a very bad choice of benchmark. The first time you execute it, it will take much longer than the runs afterwards. That's because the first ls loads stuff from disk into the VFS cache, whereas the succeeding calls can just use the cache.

Another aspect is settings. If the xterm and rxvt settings differ (e.g. size of buffer and type of fonts displayed), the comparison is worthless to begin with. On my system, these settings are about the same.

However, both scroll faster than I can read, so I don't really care about the difference

[geniux]

Code: Select all

% time aterm -e ls --color=auto -al /usr/bin/

real    0m0.489s
user    0m0.058s
sys     0m0.026s
% time aterm -e ls --color=auto -al /usr/bin/

real    0m0.488s
user    0m0.058s
sys     0m0.025s

Time to change to aterm guys

[Sleeper]

Time to change to aterm guys

Do you mean aterm now support anti-aliasing ??

[geniux]

Time to change to aterm guys

Do you mean aterm now support anti-aliasing ??

Heh, lol,
In my dreams it does

[crudh]

However, both scroll faster than I can read, so I don't really care about the difference

The difference could mean that compilation of programs, which output a lot during compilation, can take longer time in terminals where much cpu power is used for scrolling the text.

I know they did some comparisons a year ago or so and showed that gnome-terminal, which was slow as hell back then (maybe still is? ), could take way longer in certain compiles than other terminals because of too much cpu usage for scrolling the text.

[frostschutz]

I usually pipe that output to /dev/null (when I don't want to read it anyway) or into a file (because I can grep on it, and I don't need an awful big scrollback buffer for it).

Sometimes scrolling is slow not because of the terminal, but because of the application that's running in the terminal. I once tried to copy & paste a very big text into nano - it was slow as hell, because nano was stupid and updated the screen for every single character. I could almost read the text while it was being pasted and that went on for minutes. vim on the other hand seemed to notice that there was a lot of text and updated the screen less often, resulting in much faster operation, taking just a few seconds for the whole thing.

I totally agree that scrolling in a terminal should be fast... however, to me it doesn't make much of a difference wether it can scroll 10000 lines per second or 20000 (take or give a few zeroes). Who is supposed to read all that stuff?