Bug 109753

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.

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.
Network:  
3 x Remote (RH9) <-ssh->  'bad box (RH9/Fed).'  <--> 'router (fli4l)'
Remotes are 2 original RH9 and 1 upgraded w/o latest XFree update.

Symptoms:
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+%. 

Excetion:
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.  

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.

srg)

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.

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.

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.

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"
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.