Bug 109753 - really slow text rendering in xterm and gnome-terminal
really slow text rendering in xterm and gnome-terminal
Product: Fedora
Classification: Fedora
Component: XFree86 (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: X/OpenGL Maintenance List
David Lawrence
Depends On:
  Show dependency treegraph
Reported: 2003-11-11 11:33 EST by David Mansfield
Modified: 2007-11-30 17:10 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-10-12 02:31:48 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description David Mansfield 2003-11-11 11:33:40 EST
Description of problem:

compared to redhat 9 (and especially redhat 7.2 which had no
anti-aliasing) the text rendering capabilities of my desktop are
extremely limited. using 'less' on a text file in a maximized
gnome-terminal or xterm is UNUSABLY SLOW.  it takes about 15 seconds
to repaint the screen for a textfile with 1190 record length.  try it
(see below).  especially true: open a screen session in the maximized
xterm/gnome-terminal (better to choose a smaller font) and use less on
 a text file with long line lengths...  

my graphics hardware is SiS630, on a 1.4ghz Athlon system, running
stock Fedora Core 1

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

How reproducible:

Steps to Reproduce:
1. open maximized xterm or gnome-terminal
2. open screen session (exacerbates problem, not strictly necessary)
3. use 'less' on large text file with long line lengths
4. especially bad: use '>' to go to end of file, then '<' to go to
beginning.  it will take 30 seconds.  

Actual results:
takes a long time to refresh screen.  uses 100% cpu.

Expected results:
fast screen updates like other redhat/linux versions.

Additional info:
it may be XFree86, the kernel process scheduling (see related threads
in linux-kernel mailing list from about 6 months ago), font rendering
or something else ;-(

it REALLY SUX. i think I have to re-install Red Hat 9, Fedora is
UNUSABLE with this bug.
Comment 1 David Mansfield 2003-11-11 17:28:39 EST
as additional tests I should mention two things:

tried linux-2.4.22 stock kernel. no change.

by renicing the 'SCREEN' process (not 'screen' process) the extra
badness added by screen goes away and just leaves the rendering just
really slow, not unusably, terribly, horrifically slow.
Comment 2 Need Real Name 2003-11-24 08:21:17 EST
I would like to add some 'observations'. 
On RH9 / Nvidia, OB grafic, I updated to the lastet fixes (up2date) 
and rebooted to have kernel changes activated.
3 x Remote (RH9) <-ssh->  'bad box (RH9/Fed).'  <--> 'router (fli4l)'
Remotes are 2 original RH9 and 1 upgraded w/o latest XFree update.

I got > 1k x response time for gtk-imonc on bbox to the router and 
for remote X windows started on remote systems (comming in via ssh)

-The window redrawing does not happen for some >60 sec. 
-Button pressed events are handled with about the same delay.
-Mozilla windows on remote system with similar effect -but 
 +entering an URL takes seconds per/character
 +the web page builds up with significant faster.  

gtk-imonc -> 99.x% CPU.  (The window is being refreshed oftenly due 
to a grafic trafic monitor) .   
sshd during remote window handling on this box -> 98+%. 

The initial remote x-terminal (from which I connect to this bad box 
via ssh) has good response times for comming up with the command 
prompt and command outputs. 

I thought I srewed up the  bad box ( I reinstalled nvidia driver. No 
effect. glxgears remained at 500 fps).

Next I installed Fedora -- I kept /home (moved from hdb to lvm)
 glxgears at 80fps. 
 Then with nvidia installed glxgears is at about 600fps.

But the symptoms remain! 
Neither gtk-imonc nor remote sessions got faster. 
Running up2date has the same window redraw delays.  
Comment 3 Need Real Name 2003-11-26 04:21:24 EST
Additional 'observations':

A stopped couple of daemons I did not need (they were listed in
chkconfig as On)
/etc/init.d/isdn stop
/etc/init.d/spamassassin stop
/etc/init.d/bluetooth stop
/etc/init.d/privoxy stop
/etc/init.d/pcmcia stop
/etc/init.d/ipchains stop
/etc/init.d/ip6tables stop

ipchains gave a kernal mismatch error. Why was was this 'on'?
isdn, bluetooth and pcmcia - there is no hardware. Whare are they 'on'?

I  made a full install with Fedora,  but it should detect HW correctly.

The  symptoms described in my previous append eased significantly.
(I also  removed all Asian font dirs from xfs config)

CPU% for gtk-imonc and sshd are at about 50% now (comared to 99% before).

What's left:

I'm writing this note in a remote fvwm2 mozilla window (RH9 install).
Typing sometimes slows down to 3 sec per char. (scrollbar is fast)
Scrolling  the http page  is  fast same with animated grafics.
Switching xterm windows takes about 2-10 seconds. 
To open a new x-term window takes about 10 sec.
This is much faster than before - but not acceptable.

The Fedora install (2.6 GHz Athlon, !GB mem) exhibits eratic mouse
cursor behavior(contrary to smooth, between very responsive and 
jumping couple of mm). 

I hope this gives others with similar problems some clues where to
look for.
Comment 4 Mike A. Harris 2003-11-26 17:56:59 EST

This bug report is really getting out of hand above and way off
topic.  Please don't post random stuff in bug reports or ask
random off topic technical support questions in a bug report.

The services you listed are enabled by default intentionally.  It
makes no difference if you have that type of hardware or not, and
it causes no harm, and negligible startup costs.  Having the scripts
run, detect the abscense of hardware then exit, makes them "just
work" on systems that they ARE needed on.  The alternative, is
disabling them all by default, then forcing users that DO need them
to manually guess they need to enable something and then run around
trying to figure out how to do so, or the more likely scenario, is
that they'll flood Red Hat with tech support requests of the "my
ISDN/bluetooth/pcmcia/etc. doesn't work, WHY???" variety.  The
way we do this, everything works for everyone.  Anyone who sees
scripts running and is of a technically competant level to know that
they do not actually need certain scripts however is free to turn
them off for a savings of 0.0001 seconds during boot time or so.

Comment 5 Mike A. Harris 2003-11-26 18:00:46 EST
For the record, I don't consider the performance problem being
reported in this report to be an "XFree86 bug".  There is no
evidence presented that this is the case.  You may be having a
performance problem, but that could be in the individual programs
you are using themselves, or any number of other areas.  Unless
the problem is being reported by hundreds of users, I have to consider
that it is a very localized issue.  Also note that using truetype
fonts with antialiasing enabled, will make your system perform slower,
because none of the video drivers currently accelerate antialiasing.

That isn't a bug either however, it is just a fact that the drivers
are not accelerated for these operations.  The mga driver has some
acceleration for RENDER however.  I suggest using a bitmapped font
in all terminal applications, and disabling font antialiasing a.k.a.
font smoothing in the font properties panel.  If you see performance
improvements after doing that, then that is your problem, don't use
antialiased fonts.
Comment 6 Darin May 2004-01-08 05:59:09 EST
Comparing RH9 nVidia ro Fedora, simple text scrolling is noticably
slower in an xterm window (GeForce4 Ti 4600 on a 2.26GHz P4).  This is
using the default video detect from the original install.  Fedora was
a clean install and not an upgrade.

It's immidiatly clear when you're doing a simple kernel build -- you
can almost watch the lines scroll vs. them just flashing by.

I'll check the antialiasing settings and double check.
Comment 7 Mike A. Harris 2004-10-12 02:31:48 EDT
If this issue turns out to still be reproduceable in the latest
version of Fedora Core, please file a bug report in the X.Org
bugzilla located at http://bugs.freedesktop.org in the "xorg"

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.

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