Bug 139175 - xterm scrolling incredibly very slow
xterm scrolling incredibly very slow
Product: Fedora
Classification: Fedora
Component: xorg-x11 (Show other bugs)
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: X/OpenGL Maintenance List
Depends On:
  Show dependency treegraph
Reported: 2004-11-13 12:20 EST by Wayne Walker
Modified: 2007-11-30 17:10 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-04-11 10:15:27 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
lspci -v output from a Thinkpad 600x (3.09 KB, text/plain)
2004-11-21 20:41 EST, Wayne Walker
no flags Details
xorg.conf from a Thinkpad 600x (2.83 KB, text/plain)
2004-11-21 20:42 EST, Wayne Walker
no flags Details
log from a Thinkpad 600x (35.51 KB, text/plain)
2004-11-21 20:44 EST, Wayne Walker
no flags Details

  None (edit)
Description Wayne Walker 2004-11-13 12:20:10 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5)
Gecko/20041111 Firefox/1.0

Description of problem:
run a command like ls -l in both xterm and gnome-terminal

real    0m3.745s
user    0m0.061s
sys     0m0.041s

xterm :

real    1m34.555s
user    0m0.038s
sys     0m0.044s

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Open a gnome-terminal
2. cd /usr/bin
3. time ls -l
4. Open an xterm
5. Turn off jump scroll (Cntl-Middle mouse menu )
6. cd /usr/bin
7. time ls -l

Actual Results:  

real    0m3.745s
user    0m0.061s
sys     0m0.041s

xterm :

real    1m34.555s
user    0m0.038s
sys     0m0.044s

Expected Results:  The times should be on par with each other.  xterm
was faster than gnome-terminal in FC2

Additional info:

Thinkpad 600X w/ 320 MB RAM and 650 MHz P3
Comment 1 Wayne Walker 2004-11-17 13:16:09 EST
To shut up my office mate, I reloaded from scratch insteadof the
upgrade I had had.  The problem still exists.

Ihave tested on other machines, and the problem doesn't exist.  I've
tested with other terminal emulators (aterm, eterm) on this machines.
 No problem with them either.  But I've been using xterm as my
emulator since 1990, so I'm sticking with it.
Comment 2 Igor Bukanov 2004-11-21 11:47:05 EST
I was also hit by the same problem: after upgrading to FC3 from FC2
xterm stared to work incredibly slow on my 366 MHz Vaio notebook with
128 MB. Running it with nice -20 helps somewhat but still it is slower
then it was in FC3. Note that running "nice -20 ls" does not help at all.

It also seems that gnome-terminal scrolls slower then it was in FC2
but that is perhaps subjective.
Comment 3 Igor Bukanov 2004-11-21 11:58:33 EST
I just tried xterm executable from FC2 and it experience the same slow
scrolling. So the problem is not in xterm changes.
Comment 4 Wayne Walker 2004-11-21 20:39:30 EST
When this is happening, the X process is using 96+% of the CPU, so the
problem must be in the X server.  I will attach lspci output and my
xorg.conf files.
Comment 5 Wayne Walker 2004-11-21 20:41:23 EST
Created attachment 107152 [details]
lspci -v output from a Thinkpad 600x
Comment 6 Wayne Walker 2004-11-21 20:42:43 EST
Created attachment 107153 [details]
xorg.conf from a Thinkpad 600x
Comment 7 Wayne Walker 2004-11-21 20:44:51 EST
Created attachment 107154 [details]
log from a Thinkpad 600x

Although there are PM events in the log the problem is present even from a
clean boot before any suspend events.  So I doubt there are any problems
associated with power management.
Comment 8 Wayne Walker 2004-11-21 21:30:30 EST
I also switched from 24 planes to 16 planes.  That had no appreciable
effect on the performance in xterm scrolling.
Comment 9 Igor Bukanov 2004-11-22 02:07:08 EST
I booted with the last kernel from FC2 just to exclude the kernel
issue: it did not change scroll behaviour at all. On the other hand I
also see almost 100% CPU usage by X server. So the bug is related to
X11 changes.

My video hardware on Sony Vaio PCG-Z505R notebook with 366 MHz Pentiun

NeoMagic MagicMedia 256AV (laptop/notebook)

I use 64K colors as with FC2 configuration.
Comment 10 Igor Bukanov 2004-11-22 02:51:13 EST
In my case it is neomagic driver issue: 

when I replaced /usr/X11R6/lib/modules/drivers/neomagic_drv.o with the
file from FC2 distro it made xterm to fly again. Restarting Xorg with
the FC3 version of the driver restored slow scrolling.
Comment 11 Igor Bukanov 2004-11-22 03:05:36 EST
I reported the issue to freedesktop.org as:

Comment 12 Kai Hambrecht 2004-11-22 11:56:28 EST
I also had some scrolling issues on my Thinkpad 600x. I replaced the
neomagic driver with the one from fc2 (xorg-x11-6.7.0). Xterm is not
really faster than with the fc3 driver (it actually "looks" like, but
i can not measure any improvements with "time ls -la")

But i could increase scrolling speed in mozilla/firefox. With the fc3
driver i had some delays when scrolling in mozilla (xft/gtk2 build,
not in non-xft/gtk2 build). But with the old fc2 driver mozilla just
acts like i would expect.

So i think this is not only a Xorg driver issue but also a xft and/or
gtk2 issue.
Comment 13 Igor Bukanov 2004-11-22 15:18:44 EST
Kai Hambrecht wrote:

> Xterm is not really faster than with the fc3 driver (it actually
"looks" like, but i can not measure any improvements with "time ls -la")

xtrem use so called jump-scrolling by default, with the old driver I
have if I enable (-j option) / disable it (+j option):

~> time xterm -j -e ls /usr/bin

real    0m2.993s
user    0m0.862s
sys     0m0.348s
~> time xterm +j -e ls /usr/bin

real    0m3.079s
user    0m0.780s
sys     0m0.290s

Now I try the same with the new driver in FC3:
~> time xterm -j -e ls /usr/bin

real    0m4.391s
user    0m0.675s
sys     0m0.160s
~> time xterm +j -e ls /usr/bin

real    1m20.284s
user    0m0.811s
sys     0m0.254s

So the new driver caused "xtrem +j" which messures the real scrolling
performance to scroll 1m20s/3s = 17 times slower.
Comment 14 Thomas E. Dickey 2004-11-29 19:39:21 EST
I've seen some comments that blame it on the changes to
scheduling in 2.6 kernels - but when I've tried to reproduce
it, have not seen the problem.  If I could see it, there are
a few things that I could try to improve xterm's performance
based on those comments, but without something to measure
against, it's hard...
Comment 15 Kai Hambrecht 2005-01-12 03:11:08 EST
The fc2 driver, which is really several times faster than the fc3 one,
is not the best solution. Sometimes X freezes and i had to power-cycle
my Thinkpad.
But i tried the patch which is attached to freedesktop's bugzilla
entry: https://bugs.freedesktop.org/show_bug.cgi?id=1877
This patch greatly improves performance, so maybe it's worth it to
update the xorg-x11 packages.
Comment 16 Mike A. Harris 2005-01-12 03:47:52 EST
We don't supply xterm in the xorg-x11 packages, it is it's own
standalone rpm.  Changing component to xterm...
Comment 17 Mike A. Harris 2005-01-12 03:52:32 EST
How does the saying go?  "Assumption is the mother of evil"?

Due to the last few comments I assumed the patch being referenced
was an xterm patch, and commented first before reading the upstream
bug report.  Immediately then I read the bug report to find a
non-xterm patch.  ;o)

Reassigning back to xorg-x11. ;)

Can everyone CC'd on this bug report who experienced this problem
please indicate wether or not they are using "neomagic" video
hardware?  If this is the case, this patch makes sense to go into
the upstream XORG-6_8-branch if it fixes the problem and does not
incur regression of any kind.

We'll review this again once everyone has repsponded letting us
know their video hardware.

Thanks again folks.
Comment 18 Mike A. Harris 2005-01-12 03:56:52 EST
Boy, aren't I the observant one today.  The last comment in the
upstream report clearly indicates this is already in the upstream
6.8 CVS branch.  Duh.

Clearly there is something awry with my water filter.

Since we are going to be providing 6.8.2 as an update to FC3, this
problem should be fixed automatically when we update, at least for
neomagic users.  I'll leave this open for now however so everyone
can still provide their video hardware info, and so I can get
everyone to test 6.8.x from rawhide, or when we release the
erratum in the next month or so.

Sorry for all the noise.  ;)
Comment 19 Kai Hambrecht 2005-01-12 04:30:33 EST
This is my hardware:

IBM Thinkpad 600X
(--) PCI:*(1:0:0) Neomagic Corporation NM2360 [MagicMedia 256ZX] rev 0
(II) NEOMAGIC(0): VESA VBE Total Mem: 4032 kB
Comment 20 Mike A. Harris 2005-04-11 10:15:27 EDT
We've released 6.8.2 as an update to FC3 now, so this issue should be
resolved.  If the problem recurs however, please report a bug in X.Org
bugzilla at http://bugs.freedesktop.org in the "xorg" component.

Once you've filed your bug report to X.Org, if you paste the new
bug URL here, Red Hat will continue to track the issue in the
centralized X.Org bug tracker, and will review any bug fixes that
become available for consideration in future updates.

Setting status to "ERRATA"

Note You need to log in before you can comment on or make changes to this bug.