libcairo2 1.9.10 makes Ubuntu 10.10 slow

Bug #595845 reported by Ubeer
146
This bug affects 29 people
Affects Status Importance Assigned to Milestone
cairo (Ubuntu)
Fix Released
Medium
Unassigned

Bug Description

Binary package hint: update-manager

Description: Ubuntu maverick (development branch)
Release: 10.10

apt-cache policy update-manager:
  Installed: 1:0.142.1
  Candidate: 1:0.142.1
  Version table:
 *** 1:0.142.1 0
        500 http://archive.ubuntu.com/ubuntu/ maverick/main Packages
        100 /var/lib/dpkg/status

When I open up the update manager it reads the package lists, does something else and then goes into "Building data structures" and at that point Xorg start to take up 100% of my CPU and everything crawls to a halt. This can run for a minute or two and then it's ready and shows the updates that are available.

I have the xorg-edgers ppa enabled. Later today I'll try without the ppa and see if the problem still exists.

Update: I purged the xorg-edgers and the problem is not there anymore. Although there is still a spike in the Xorg 'computation' when it's building the data structures.

ProblemType: Bug
DistroRelease: Ubuntu 10.10
Package: update-manager 1:0.142.1
ProcVersionSignature: Ubuntu 2.6.35-4.5-generic 2.6.35-rc3
Uname: Linux 2.6.35-4-generic i686
Architecture: i386
Date: Fri Jun 18 10:51:02 2010
InstallationMedia: Ubuntu 10.04 "Lucid Lynx" - Beta i386 (20100406)
PackageArchitecture: all
ProcEnviron:
 LANG=en_US.utf8
 SHELL=/bin/bash
SourcePackage: update-manager

Revision history for this message
Ubeer (berendbotjeginguitvaren) wrote :
description: updated
Revision history for this message
P0per (chrispope) wrote :

After upgrading to maverick I have noticed this problem. While update-manager is in the "Building Data Structures" state, Xorg CPU usage is 80%+ on my Core2Quad6600. There are other situations in which Xorg consumes an unusually high amount of CPU time. Examples:
- Frequently adding lines of text in gnome-terminal (eg. output while running apt-get upgrade)
- Scrolling pages in firefox
- Scrolling text in Eclipse

It appears that xorg is inefficiently repainting large areas of the screen, and update-manager is one was to reliably reproduce this issue.

Video card is nvidia GeForce GTS 8600 running current nvidea proprietary driver.

Is there any diagnostic information I can provide?

Revision history for this message
bbordwell (benbordwell) wrote :

I am getting this bug with nouveau driver. It takes update-manager over 10 min. to start and xorg is using 100% cpu the whole time. I will try and look into how to get more info for this bug but I am not very familiar with xorg or update-manager.

Changed in update-manager (Ubuntu):
status: New → Confirmed
Revision history for this message
bbordwell (benbordwell) wrote :

Not sure it will be useful but here is an strace.

Revision history for this message
Michael Vogt (mvo) wrote :

With the help of bbordwell on irc we managed to fix part of the problem by limiting the amount of "set_fraction" calls to the progressbar.

Changed in update-manager (Ubuntu):
status: Confirmed → Fix Committed
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package update-manager - 1:0.142.3

---------------
update-manager (1:0.142.3) maverick; urgency=low

  * merged lp:~and471/update-manager/fix-bug-386196, many thanks
  * DistUpgrade/DistUpgradeView*.py:
    - port progress to new python-apt 0.8 API
  * merged lp:~mdz/update-manager/small-fixes-20100707, many thanks
  * DistUpgrade/DistUpgradeViewGtk.py:
    - call progressbar.set_fraction() less often to avoid too much
      CPU consumption on certain graphic drivers
  * UpdateManager/GtkProgress.py:
    - limit the amount of set_fraction() here too (LP: #595845)
  * UpdateManager/UpdateManager.py:
    - disconnect the model before adding lots of new items, this
      speeds up the building of the view massively
 -- Michael Vogt <email address hidden> Fri, 09 Jul 2010 10:07:34 +0200

Changed in update-manager (Ubuntu):
status: Fix Committed → Fix Released
Revision history for this message
Bowmore (bowmore) wrote :

I'm not sure this is the proper way to solve the cpu load for the progress bar.

The proress bar is used i other apps too and this solutions above then will have to be specified in a design rule or finally fixed in other ways. For example, the panel app "ontv" uses the progress bar per tv channel and many channels causes a heavy cpu (xorg) load as well. So I'm looking forward to a final solution the the progress bar issue(s).

Furthermore, update-manager (1:0.142.3) maverick doesn't give a noticable change in load to me.
Graphic driver: radeon

Revision history for this message
Bowmore (bowmore) wrote :

Further investigations show that it's theme dependent

Test case:
- Panel app "ontv" with some 10-15 channels gives

Lucid cpu load:
- Ambiance 60-65%
- Clearlooks 1-2%

Maverick cpu load:
Ambiance 90% (progress bar longer than i Lucid)
Clearlooks 1-2%

Buildning data structures progress time due to cpu load

- Ambiance 20-25 sec (high load)
- Clearlook 5-7 sec

So the workaround to me is to run a theme like Clearlooks, Darkroom, Moomex, etc

Revision history for this message
Noel J. Bergman (noeljb) wrote :

I still see this problem with Maverick, even with update-manager 1:0.142.3. Everything is up-to-date, and I am using the real nvidia driver, not nouveau. I confirm Bowmore's observation that it is theme dependent; Clearlooks is fine, Ambiance, Radiance and Dust are not.

Revision history for this message
Bowmore (bowmore) wrote :

The root of the bug, high xorg load, has not be solved so marking it as Confirmed.

Note that this bug applies to all apps using the progress bar where some of them generates a very high load for a number of themes.

Tested themes causing high progress bar load
- Ambiance
- Dust
- Dust Sand
- Hanso
- Homosapien
- Human
- Impression
- Night impression
- Raidiance

Changed in update-manager (Ubuntu):
status: Fix Released → Confirmed
Revision history for this message
plun (plun) wrote :

I can confirm this when changing to Ambiance as theme, update-manager also crashes for me.

High Xorg load and also high CPU load noticed.

Revision history for this message
bbordwell (benbordwell) wrote :

mvo, update-manager is working much better for me than before, but like others I am still getting 100% cpu load from xorg on building data structures and it is still slower than lucid. If you want to investigate this more we can schedule a time to meet on IRC again, otherwise good work so far!

Revision history for this message
Harry (harry33) wrote :

Just happened to find this bug report.

Have you thought that there is one package behind all this sluggishness (caused by high CPU load).
The name of the package IMO is libcairo2, and precisely the 1.9 branch (newest in maverick is 1.9.12.-1 right now, newest snapshot is 1.9.14).
The problem seems to be that libcairo2 has been changed from the 1.8 branch (1.8.10 in lucid) so much that is has begun to be incompatible with nvidia proprietary drivers (up to 256.35).

You can test this simply by customizing any theme not to use gradients / color blends.
This can be achieved by opening the theme manager (appearance-properties), then customizing any theme by selecting from Controls "Mist". Any Colors, Window Border, Icons and Pointer can be selected, but use Mist from Controls.
You will notice a huge speed improvement.

This does not fix the bug, it only ceases to use theme gradients / color blends.

Revision history for this message
Harry (harry33) wrote :

You might also want to take a look at the these:
bug #601220
bug #605386
bug #605979
bug #606606

Revision history for this message
Bowmore (bowmore) wrote :

@Harry
The high cpu-load affect both ATI and NVidia but not Intel graphics as far I've seen . Myself I have a Radeon 9800 Pro running the open driver that is heavily affected by this high load.

The libcairo2 1.9 branch might affect nvidia further but the 1.8 branch causes the same problem i Lucid, however not that obvious for e.g. update manager since the progress bar there is held in a popup windows and thus much smaller.

The fix to me is to use another theme.

bbordwell (benbordwell)
Changed in update-manager (Ubuntu):
importance: Undecided → Medium
status: Confirmed → Triaged
Revision history for this message
Michael Vogt (mvo) wrote :

This is not update-manager specific. Attached is a tiny pygtk app that demos the problem.
It takes 1.4s to run on my ati card on maverick and up to 3s on my nvidia card (with nouveau).

affects: update-manager (Ubuntu) → cairo (Ubuntu)
Revision history for this message
Michael Vogt (mvo) wrote :

When LD_PRELOADING the old cairo performance is at ~0.2s.

Changed in cairo (Ubuntu):
milestone: none → maverick-alpha-3
summary: - During "Building data structures" when starting the update-manager Xorg
- takes up 100% cpu
+ libcairo2 1.9.10 makes Ubuntu 10.10 unusably slow
Revision history for this message
Bowmore (bowmore) wrote : Re: libcairo2 1.9.10 makes Ubuntu 10.10 unusably slow

Note that there's both a load and a time issue.

A progress bar shall NEVER neither cause a high load nor a time prolongation of the progress itself. It shall be there only to indicate. My feeling is that this progress bar used by e.g. Ambiance is a pure design issue, i.e has to be redesigned.

Today I made another install of Ubuntu using that progress bar and wondered whether the progress bar itself caused a prolongation of the installaltion process. Maybe or maybe not but the suspicion is there for obvious reasons.

The example script also indicates all this with a time factor of around 4 and an unreasonable high load.

Michael Vogt (mvo)
summary: - libcairo2 1.9.10 makes Ubuntu 10.10 unusably slow
+ libcairo2 1.9.10 makes Ubuntu 10.10 slow
Revision history for this message
Yotam Benshalom (benshalom) wrote :

This bug may be related or even a duplicate:
https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/612614

Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package cairo - 1.9.14-1ubuntu1

---------------
cairo (1.9.14-1ubuntu1) maverick; urgency=low

  * debian/patches/01_fix_slowness.patch:
    - apply patch from seb128 to fix slow progress bar on cards
      that do not implement server-side gradients (LP: #595845)
 -- Michael Vogt <email address hidden> Wed, 04 Aug 2010 12:02:21 +0200

Changed in cairo (Ubuntu):
status: Triaged → Fix Released
Revision history for this message
Harry (harry33) wrote :

I confirm, the bug is fixed now.
Also these are fixed as well:
bug #601220
bug #612614

Revision history for this message
Bowmore (bowmore) wrote :

I would say partly fixed.

The time issue, e.g. for update manager to "Building data structures", seems to be solved.

The cpu load issue is still there:
- Ambiance 80-90%
- Clearlooks 1-2%
for the Ontv test case I mentioned earlier.

My opinion is that e.g progress bars shall not cause high cpu loads.

Revision history for this message
Sebastien Bacher (seb128) wrote :

> The cpu load issue is still there:
- Ambiance 80-90%
- Clearlooks 1-2%

* is that specific to Ontv?
* Was that an issue in lucid? or in maverick using cairo 1.8?
* do you get the same issue using other murrine themes?

Seems that would rather be a theme issue than a cairo one

Revision history for this message
Bowmore (bowmore) wrote :

> is that specific to Ontv?
I don't think so. Ontv is a means to me to compare the cpu load for different types of progress bars/themes.

> Was that an issue in lucid? or in maverick using cairo 1.8?
Yes, comment #8 above confirms that the load issue is present in Lucid as well.

> do you get the same issue using other murrine themes?
Yes, comment #10 lists the problematic themes.

Revision history for this message
Aaron Plattner (aplattner) wrote :

P0per, when you say you are using "current" NVIDIA drivers, which version, exactly, are you using? The latest drivers accelerate gradients on all GeForce 8 series and up GPUs, and should be quite fast.

Revision history for this message
Kristopher Ives (krisives) wrote :

Caps out a core when a SSH starts showing lots of text for me

Revision history for this message
Vitaly (vbabiy86) wrote :

Here is a video of what I see happen, When there is a lot of output on gnome terminal xorg cpu usage is huge

Revision history for this message
Florin Coras (fcoras) wrote :

I'm also experiencing these problems, and I'm speaking about high CPU usage due to xorg when scrolling in applications (eg. Firefox, terminator, pidgin and other). I'm using maverick beta with libcairo2 1.10.0 and nvidia-current 256.53 .

The bug title might be in line with what we're experiencing but, maybe, the description should have a wider scope.

Revision history for this message
Joe_Bishop (denis-cheremisov-gmail) wrote :

IMO, they better postpone this release to wait for better drivers or even pass it completely. This one is just unusable, it's too slow.

Revision history for this message
Dustan Ashley (dashley) wrote :

I can also confirm this issue, not sure if libcairo is truly to blame, but this slowness was the first thing I noticed on my freshly installed 10.10 beta (fully updated).

Quickly scrolling through lines of text in gnome-terminal is enough to cause X to completely consume 1 core on my Q6600 and the perceived user experience is really bad.

2.6.35-19 x86_64
nVidia GTX 460 with 256.53 driver

Revision history for this message
Dustan Ashley (dashley) wrote :

Following up, I went and obtained the latest nVidia beta drivers for Linux x86_64 (driver version 260.19.06), and it appear to have resolved, or at least greatly improved this problem.

Revision history for this message
Sebastien Bacher (seb128) wrote :

the new comments seem an nvidia driver issue rather than a cairo one

Revision history for this message
capacman (achalil) wrote :

I think it is nvidia since i encountered with same slowness in KDE also.

Revision history for this message
Gábor Szécsi (deje07) wrote :

I still have the sluggishness problem, it is very annoying. Ubuntu 10.10 final, libcairo 1.10 and NVidia proprietary driver 260. Switching to Clearlooks or similar solves my problem.

Revision history for this message
Gábor Szécsi (deje07) wrote :

Bad luck: novoeau suffers also. It seems libcairo 1.10 has some serious issues.

Revision history for this message
Ben Shadwick (benshadwick) wrote :

I just noticed this in Ubuntu 10.10 Maverick amd64 while running Update Manager via a Neatx session from the nomachine windows NX client.

Revision history for this message
owise1 (o-wise-1) wrote :

I also have this bug. Updated to 10.10 and had problem with X so am running novoeau due a problem with the legacy drivers for my old MX440 nvidia card.

Tried the clearlooks theme and while it appeared to make a small improvement - you can see the progress bar actually moving, Xorg is running at 75% CPU utilization while the progress bar is in the "building data structures" phase. This occurs regardless of weather update manager is the visible window or not.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.