Re: Really slow xterm
cothrige <cothrige@bellsouth.net> wrote:
> * Thomas Dickey (dickey@saltmine.radix.net) wrote:
>> cothrige <cothrige@bellsouth.net> wrote:
>> > Actually, it has been worse at times than even above. Yesterday, I
>> > ran the same test and it took 20 seconds. I thought that was pretty
>> > awful.
>>
>> But at the same time rxvt would be running slower (due to your system load)
>> since it's based on the load presented.
> No, actually rxvt still ran as usual, and mrxvt a bit quicker still.
> I would naturally expect both to be a bit quicker than xterm, but I
> don't recall it ever being so obvious as it seems now. While rxvt
> seems pretty normal, regardless of the load, xterm always scrolls the
> text so slowly that it is very, very obvious. I used to use
> xterm quite often, and it just never looked and acted this way. It
> actually reminds me of using a framebuffer console in how it is
> working right now.
huh. Occasionally I see comments regarding X servers and "very slow".
But nothing that I've seen first hand. The two issues that I've seen
and measured are (1) XCopyArea function and (2) xterm's scrolling area
stored as one big chunk which is shifted. The XCopyArea problem occurs
for "any" scrolling size on the local host while the big-chunk is a problem
for "large" chunks.
A couple of years ago, there was a third - which comes back now/then as
defects are added/removed in the 2.6 kernels (the sched_yield function
is used to work around this, but _that_ has been broken 2-3 times ;-).
>> On the other hand, running xterm remotely, I've measured rxvt running 5 times
>> slower than xterm.
>>
>> (though why someone realistically would do "ls -l /usr/bin" hasn't been said)
> Well, the situation is that when I am using xterm the screen is
> drawing and outputting very slowly. Very visibly so. I ran 'time ls
> /usr/bin' simply as a test for the speed of the terminal emulators.
> Since that directory was large I figured that I would get the best
> most informative results by doing that.
scrolling is one place to measure, but there are several (font choice
is another, e.g., Xft is notoriously slow). Older versions of rxvt
would stop refreshing while they were getting input, and then paint
the final screen (usually faster, but with some drawbacks).
--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net
Reply to: