libcairo2 1.9.10 makes Ubuntu 10.10 slow

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?

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.

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

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.

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

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

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

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.

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

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.

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!

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.

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

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

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

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

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.

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

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

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

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.

> 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

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

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.

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

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

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.

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.

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

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.

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

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

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.

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

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

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.