cothrige <[EMAIL PROTECTED]> wrote: > * Thomas Dickey ([EMAIL PROTECTED]) wrote: >> cothrige <[EMAIL PROTECTED]> 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
