f14 gnome unusable

[Brian Ericson]

Just upgraded to f14.

The upgrade itself was smooth (thanks!), but Gnome's (UI) performance 
has completely and utterly tanked.  If I open a terminal and a second 
tab in the terminal, switching between tabs takes upwards of 4 seconds.  
Same thing with FireFox tabs (Chrome/Chrome tabs are fine, though).  The 
blue highlighting of Gnome menus is incapable of following even a 
slow-moving mouse, alt-tab takes forever, and repainting minimized 
windows is awful.

Basically, I got better GUI performance out of f13 with all my CPUs and 
drives pegged than I'm getting now on an idle system.

Interestingly, KDE isn't impacted at all by any of this and even Gnome 
apps (like terminal) are snappy. I even went so far as to create a new 
user to see if some f13 Gnome configuration is the culprit, but the new 
user has exactly the same issues.

Has anyone else encountered this?  Anyone know what to do to fix it?

[Steve Berg]

>  http://forums.fedoraforum.org/showthread.php?t=253668
>
>  Quoting the relevant bit:
>  Update - apparently this issue is related to the GTK theme in use. The
>  default (Fedora, or Clearlooks, or a few others) results in this slow
>  behaviour. Other themes, like Nodoka and a few others perform fine. 
Seeing the same slowdown on three different F14 installs here.  The Nimbus
themes seem to perform normally.

-- 
*       Stephen Berg       *
*  sberg(a)mississippi.com   *
*  Sinners can repent,     *
*  But stupid is forever.  *

[Brian Ericson]

http://forums.fedoraforum.org/showthread.php?t=253668

Quoting the relevant bit:
Update - apparently this issue is related to the GTK theme in use. The 
default (Fedora, or Clearlooks, or a few others) results in this slow 
behaviour. Other themes, like Nodoka and a few others perform fine.

On 11/03/2010 01:42 PM, Brian Ericson wrote:
>  Just upgraded to f14.
>
>  The upgrade itself was smooth (thanks!), but Gnome's (UI) performance
>  has completely and utterly tanked.  If I open a terminal and a second
>  tab in the terminal, switching between tabs takes upwards of 4 seconds.
>  Same thing with FireFox tabs (Chrome/Chrome tabs are fine, though).  The
>  blue highlighting of Gnome menus is incapable of following even a
>  slow-moving mouse, alt-tab takes forever, and repainting minimized
>  windows is awful.
>
>  Basically, I got better GUI performance out of f13 with all my CPUs and
>  drives pegged than I'm getting now on an idle system.
>
>  Interestingly, KDE isn't impacted at all by any of this and even Gnome
>  apps (like terminal) are snappy. I even went so far as to create a new
>  user to see if some f13 Gnome configuration is the culprit, but the new
>  user has exactly the same issues.
>
>  Has anyone else encountered this?  Anyone know what to do to fix it?

[Brian Ericson]

To test that, I compared my W510 against a friend's W500 (which had also 
been upgraded).  We started "top" and then selected 
"System->Preferences" and using the down-arrow key to cycle through the 
menu options.  "top" showed XOrg topping my CPU at up to 99%, his CPU 
maybe hit 10% at one point.  You are correct in that when Gnome is doing 
whatever-it-is-that-is-slow, XOrg is taking up significantly more CPU 
than it does on a normal system.

The W510 has an nVidia Quadro FX 880M, which is "fairly" new and I've 
been using the nvidia drivers (at the native resolution of 1920x1080).  
Switching to nouveau (which chose 1024x768) resulted in normal behavior 
(everything became snappy again).

So, it appears there's something "up" with nVidia/Gnome/XOrg. :(

I wonder if anyone else using gnome + nvidia on a machine with an 880M 
would also experience the same annoying. behavior...

Thoughts?

On 11/03/2010 03:56 PM, stan wrote:
> > On Wed, 03 Nov 2010 14:43:35 -0500
> > Brian Ericson<bericson(a)ptc.com>  wrote:
> > Thanks for the reply!  If only...  It's acting as though it's under
> > significant load, but top/iotop/etc. show a completely idle system.
>  That sounds like it is internally spinning its wheels.  It should show
>  up in top though as CPU cycles being spent uselessly.
>
>  What could slow down things without using CPU cycles?
>
>  Contention on the hardware bus?  Try unplugging and replugging your
>  keyboard and mouse.
>
>  How about overheating?  Is it possible the system is now slowing down
>  the CPU significantly because it is too hot?
>
>  I'm at a loss, especially since KDE functions normally and some
>  functions in Gnome work fine.
>
>  Certainly something strange going on.  Are you fully updated to the
>  latest packages?

[stan]

>  On Wed, 03 Nov 2010 14:43:35 -0500
>  Brian Ericson <bericson(a)ptc.com&gt; wrote: 
>  Thanks for the reply!  If only...  It's acting as though it's
> under 
>  significant load, but top/iotop/etc. show a completely idle system. 
That sounds like it is internally spinning its wheels.  It should show
up in top though as CPU cycles being spent uselessly.

What could slow down things without using CPU cycles?

Contention on the hardware bus?  Try unplugging and replugging your
keyboard and mouse.

How about overheating?  Is it possible the system is now slowing down
the CPU significantly because it is too hot?

I'm at a loss, especially since KDE functions normally and some
functions in Gnome work fine.

Certainly something strange going on.  Are you fully updated to the
latest packages?

[Brian Ericson]

Thanks for the reply!  If only...  It's acting as though it's under 
significant load, but top/iotop/etc. show a completely idle system.

On 11/03/2010 02:28 PM, stan wrote:
>  On Wed, 03 Nov 2010 13:42:03 -0500
>  Brian Ericson<bericson(a)ptc.com>  wrote:
>
> > Has anyone else encountered this?  Anyone know what to do to fix it?
>  When I fresh installed F14, there were delays such as you mention on
>  the gui with Gnome.  I checked top and iotop to see what was holding
>  up the works.  And it turned out there were background jobs running.
>  Most of those will complete if you give them an overnight, and you
>  should only hit problems when they are updating after that.
>
>  I changed the cron jobs so they would always defer to the gui, and
>  things are OK now.  Used ionice as it seemed to be mostly io causing the
>  problem.

[Jason E. High]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 11/03/2010 03:28 PM, stan wrote:
>  On Wed, 03 Nov 2010 13:42:03 -0500
>  Brian Ericson <bericson(a)ptc.com&gt; wrote:
>   
> > Has anyone else encountered this?  Anyone know what to do to fix it?
>  
>  When I fresh installed F14, there were delays such as you mention on
>  the gui with Gnome.  I checked top and iotop to see what was holding
>  up the works.  And it turned out there were background jobs running.
>  Most of those will complete if you give them an overnight, and you
>  should only hit problems when they are updating after that.
>  
>  I changed the cron jobs so they would always defer to the gui, and
>  things are OK now.  Used ionice as it seemed to be mostly io causing the
>  problem. 
I did a fresh install and haven't noticed any unusual lag.  Thunderbird
was slow at first because I configured it with my Gmail account and it
was downloading all of my messages, but that's about it.

- -- 
Jason E. High
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
>
> iQEcBAEBAgAGBQJM0bh6AAoJEDY8fBBoDllH9nkIAPeFhdXz5ECGZvLgH21Y+LSa
> 14fUZYNGw/nPOHHOPgx3vsyGvYognKKWbjbo7iYmI2cCDaFpIIwJxdMdOZn5MJVV
> EWjpdOcSDGTZj0SzfQhZdQrVkMSo0x/+c5XZLcFfPxma5Ao+ZCF7VZnz5VhbryfE
> 4PO7vvDDS3lO9i9u/fQy9MoVRNxdLObYMixB99AAj9LerXi/vdC9IRLNvs+06oOu
> d9lojNyKqvDKOy46gPpPFTrOzRH38ZFVJRqsTl9eGQieMCSZ/UEngZIgMrxAnN44
> cyWtRxrcdc0C85z7sTLd+XZuVgXcDqEq6Yfh7gtoDWe5SIaMan54rTzorXQQZDM=
> =0Noj
> -----END PGP SIGNATURE-----

[stan]

On Wed, 03 Nov 2010 13:42:03 -0500
Brian Ericson <bericson(a)ptc.com&gt; wrote:
 
>  Has anyone else encountered this?  Anyone know what to do to fix it?
When I fresh installed F14, there were delays such as you mention on
the gui with Gnome.  I checked top and iotop to see what was holding
up the works.  And it turned out there were background jobs running.
Most of those will complete if you give them an overnight, and you
should only hit problems when they are updating after that.

I changed the cron jobs so they would always defer to the gui, and
things are OK now.  Used ionice as it seemed to be mostly io causing the
problem.

[Rahul Sundaram]

On 11/04/2010 04:49 AM, Brian Ericson wrote:
>  I wonder if anyone else using gnome + nvidia on a machine with an
> 880M 
>  would also experience the same annoying. behavior...
>
>  Thoughts? 
Try this.  Create another user and login and see if it works better? 
You might have some old configuration files creating problems.

Rahul

[Mark Eggers]

On Thu, 04 Nov 2010 12:27:48 -0500, Steve Berg wrote:

> > http://forums.fedoraforum.org/showthread.php?t=253668
> >
> > Quoting the relevant bit:
> > Update - apparently this issue is related to the GTK theme in use. The
> > default (Fedora, or Clearlooks, or a few others) results in this slow
> > behaviour. Other themes, like Nodoka and a few others perform fine.
>  
>  Seeing the same slowdown on three different F14 installs here.  The
>  Nimbus themes seem to perform normally.
>  
>  --
>  *       Stephen Berg       *
>  *  sberg(a)mississippi.com   *
>  *  Sinners can repent,     *
>  *  But stupid is forever.  * 
Fedora 14 on a 2.6 GHz P4, overclocked 7600GS
Using either NVidia 260.19.12 or 256.53

Had the same problem here. Most of the time I run WindowMaker or KDE, so 
the slowdown didn't bother me.

Then I made the mistake of running gnome mines . . . 100% CPU 
utilization, poor screen refresh once it recovered, and a variety of 
other unpleasantness.

I prowled around on the NVidia forums and someone had posted the same 
issues. It seems that the problem (according to this poster) is with the 
NVidia drivers (all recent versions), Xorg 1.9, and cairo/cairomm 1.10.

It really appears to be an NVidia driver issue. Other issues with 
260.19.12 include the inability to overclock and crashes in some 
applications linked with SDL, pulseaudio, and GL.

Reverting back to 256.53 fixes the overclocking and program crashes, but 
doesn't fix the problems with applications that use cairo/cairomm.

In order to fix those issues, the poster recommended downgrading to the 
last 1.8 version available in Fedora 13. I basically followed the 
poster's instructions and did this:

1. Created a file /etc/yum.repos.d/fedora-13.repo containing:

[fedora13]
name=Fedora 13 - $basearch
failovermethod=priority
baseurl=http://download.fedoraproject.org/pub/fedora/linux/releases/13/Ev...
enabled=1
metadata_expire=7d
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-$basearch

2. Created a file /etc/yum.repos.d/fedora-13-update.repos containing:

[f13-updates]
name=Fedora 13 - $basearch - Updates
failovermethod=priority
baseurl=http://mirrors.usc.edu/pub/linux/distributions/fedora/linux/updat...
enabled=1
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-$basearch

3. Ran the following command:
yum --nogpgcheck --noplugins --disablerepo=* --enablerepo=fedora13 downgrade cairo cairomm
cairo-devel cairomm-devel

(all on one line)

If you're running x64, make the appropriate adjustments.

4. Restart the X server (I rebooted)

Now I can run gnome mines without locking up the system, and font 
rendering is back to what it was with Fedora 13.

I don't know what other issues will occur with this downgrade since I've 
only been running this configuration for about 20 minutes.

Hopefully NVidia will fix their drivers.

Also from the NVidia forums, the nouveau drivers do not have this issue.

Hope this is useful.

. . . . just my two cents.

/mde/

[Mark Eggers]

On Wed, 03 Nov 2010 18:19:27 -0500, Brian Ericson wrote:

>  To test that, I compared my W510 against a friend's W500 (which
> had also
>  been upgraded).  We started "top" and then selected
>  "System->Preferences" and using the down-arrow key to cycle through the
>  menu options.  "top" showed XOrg topping my CPU at up to 99%, his CPU
>  maybe hit 10% at one point.  You are correct in that when Gnome is doing
>  whatever-it-is-that-is-slow, XOrg is taking up significantly more CPU
>  than it does on a normal system.
>  
>  The W510 has an nVidia Quadro FX 880M, which is "fairly" new and I've
>  been using the nvidia drivers (at the native resolution of 1920x1080).
>  Switching to nouveau (which chose 1024x768) resulted in normal behavior
>  (everything became snappy again).
>  
>  So, it appears there's something "up" with nVidia/Gnome/XOrg. :(
>  
>  I wonder if anyone else using gnome + nvidia on a machine with an 880M
>  would also experience the same annoying. behavior... 
I have an older card (OK, really old) 7600GS that I overclock in order to 
get reasonable performance. A few things that I've noted:

Upgrading to the latest drivers (260.19.12) causes all sorts of problems. 
Games compiled with OpenGL will fault (segmentation fault), and I cannot 
overclock with that version of the driver. Running 256.53 solves those 
problems (can overclock, game does not segfault).

I've noticed about a 5 percent performance loss via glxgears in going 
from Fedora 13 to Fedora 14. I've not done the extensive graphics test 
(specviewperf), but performance does "feel" slower.

I've also noticed some performance issues when running a GtK application 
such as pan under WindowMaker. When I switch virtual desktops away from 
the one containing pan and then back, I see a momentary spike in CPU and 
a pause while the window refreshes.

I haven't done a lot of work in KDE yet, so I don't know what (if any) 
performance impact exists.

I'm running Samsung SyncMaster at 1680x1050x24 with 96x96 resolution. The 
monitor is attached via a digital cable.

Looks like there is a performance regression, although nothing like what 
you're experiencing. I also see that Xorg is using more memory than I 
remember it using in Fedora 13.

What version of the NVidia driver are you using?

. . . . just my two cents

/mde/