03-turn_on_buggy-repeat_handling.dpatch causes slowdown in Evolution

Bug #219587 reported by Lukáš Lalinský on 2008-04-19
Affects Status Importance Assigned to Milestone
cairo (Ubuntu)
Sebastien Bacher

Bug Description

After upgrade to Hardy I've noticed that redrawing in Evolution was very slow. A quick google search led me to http://thread.gmane.org/gmane.os.freebsd.devel.gnome/25373, so I checked if the Ubuntu package contains the same patch. According to http://cairographics.org/news/cairo-1.5.18/ the bug affects only xorg 1.3 and older (Hardy has xorg 1.4), and the workaround should be already in cairo 1.6. So I tried to recompile the package without 03-turn_on_buggy-repeat_handling.dpatch and it indeed fixed the slowness. Since Hardy no longer needs the patch, I suggest dropping it from the package.

Sebastien Bacher (seb128) wrote :

Thank you for your bug report. Alexander, Fabien, the patch has been added to workaround firefox 3 issue, could you confirm if it's required or not?

Changed in cairo:
importance: Undecided → Medium
Alexander Sack (asac) wrote :

This bug affects every X server that uses XAA OffscreenPixmaps. e.g. even 1.4.1

We switched our default X setup to not use Offscreen Pixmaps, so we could disable this patch. However, this switch was done pretty late in the cycle so i am not sure if it really cures every corner of this bug.

I'd say that we should disable this patch for intrepid right in the beginning and consider to disable it for 8.04.1, but not for release.

Fabien Tassin (fta) wrote :

I agree with asac, we should keep the patch for hardy, just because it's too late.
I'm concerned by the 2nd part of the message in http://cairographics.org/news/cairo-1.5.18/

   "(Meanwhile, there appears to be a separate bug where some X
    servers or specific X-server drivers will use random pixmap data
    when asked to draw a repeating surface. The buggy_repeat
    workaround would also avoid those problems, but we have not yet
    characterized whether the new "version < 1.4" is a good
    characterization of those problems or not.)"

I think ATI (fglrx) is one of those. I will test locally (as I used to have that issue).

Alexander Sack (asac) wrote :

> I think ATI (fglrx) is one of those. I will test locally (as I used to have that issue).

to my knowledge its every driver that doesn't ship its own Xaa implementation (e.g. vanilla X xaa) in combination with offscreen pixmaps.

The uncertainty of cairo devs at the time of that announcement was due to the fact that fedora disabled offscreen pixmaps for some time now and thus, there was confusion, because the same version that didn't work for ubuntu worked over there.

However, we don't know 100% and should get proper testing on this in -updates to be sure that the initial mozilla rendering bug (and X _crashes_ in some cases) doesn't reappear for some users if we drop this patch.

Alexander Sack (asac) wrote :


Alexander Sack (asac) wrote :

this bug is triaged. we just need more testing. milestoning for 8.04.1.

Changed in cairo:
milestone: none → ubuntu-8.04.1
status: New → Triaged
Martin Pitt (pitti) wrote :

Unmilestoning since Alex and Fabien believe that it is not really appropriate for an SRU. Also, please get it fixed in intrepid first.

Changed in cairo:
milestone: ubuntu-8.04.1 → none
Changed in cairo:
importance: Undecided → Medium
status: New → Confirmed
milestone: none → ubuntu-8.04.1
Sebastien Bacher (seb128) wrote :

after speaking with a friend who was considering switching away from evolution because the hardy version is too slow on his desktop and laptop configurations (intel and nvidia video cards, no special xorg configuration changes) and figuring that the slowness is due to this workaround I think we should reconsider that, I've milestoned the bug again and uploaded a new revision reverting the change, let me know if you disagree but I think we should give to hardy-proposed testing

Martin Pitt (pitti) wrote :

Accepted into -proposed, please test and give feedback here

Changed in cairo:
milestone: ubuntu-8.04.1 → none
status: Confirmed → Fix Committed
Steve Langasek (vorlon) wrote :

There is significant potential for regression here. Verification of this SRU should include getting feedback from the subscribers of bug #186186, who reported the video glitches in the first place.

Øyvind Stegard (oyvinst) wrote :

I just updated the Cairo library from hardy-proposed, and the speed-difference in Evolution is significant, it's much better now. You easily notice it by for instance changing size of the columns in the message list view (used to be embarassingly slow). I haven't seen any other problems yet, Firefox looks ok, etc. I'm using the newest fglrx-driver from AMD (Catalyst 8.5), and I don't use any special options in xorg.conf. If I see any sign of corruption or other problems after this upgrade, I'll post it here.

Gustavo Carneiro (gjc) wrote :

Firefox is much faster now, after the update. GMail used to be dog slow, except the "Older Version" of GMail (https://mail.google.com/mail/?ui=1). Now both new and old versions are fast. Also google maps is much faster now.

Definitely a great update :-)

Martin Pitt (pitti) wrote :

I have used the update for a week now and did not notice any differences. It neither got noticeably faster, nor did it break anything (amd64, GeForce 5200, nvidia-glx-new). Admittedly I didn't notice any particular slowness in Evolution before, either.

Øyvind Stegard (oyvinst) wrote :

I *did* notice the speed-ups, particularly in Evolution. For my case (AMD Catalyst 8.5 fglrx-driver), Evolution was especially slow with this work-around enabled. I have not noticed any sign of corruption at all, since I updated the Cairo-library.

Filip Palm (filip) wrote :

I have not had the time for any extensive testing but my initial feeling is that this fixes the problem i have in bug #225950.

When i come home from my vacation im going to test this some more...

Martin Pitt (pitti) wrote :

Please upload this fix to Intrepid ASAP, for wider testing.

Changed in cairo:
assignee: nobody → seb128
milestone: none → intrepid-alpha-2
Sebastien Bacher (seb128) wrote :

I've been running the updated version on machine using ati and intel video cards and noticed no issue, I didn't notice the speed difference either but drawing was not slow on those configurations or I'm not using it in a way which triggers the slowness issue

Alexander Sack (asac) wrote :

after re-reviewing my ffox bugmail I found a potential regression bug 237594; unfortunately, reporter reinstalled his system so i couldn't triage. I followed up anyway now and he states [1] that he most likely had hardy-proposed enabled and that the bug started on the day he reported it (which was 1/2 days after we pushed this to -proposed).

[1] - https://bugs.launchpad.net/ubuntu/+source/firefox-3.0/+bug/237594/comments/10

Sebastien Bacher (seb128) wrote :

the issue you mention is one which can happen when the user modify the xorg configuration to use options upstream doesn't recommend right? in such case I would say it's the user responsability and there is no reason to impact on performances for all other users just to avoid breakages for users doing such changes

Alexander Sack (asac) wrote :

No, his xorg.conf suggests that he has default options.

Steve Langasek (vorlon) wrote :

Given that there has only been one bug reported that /may/ be linked to this change, and it is now not reproducible and has not been corroborated by any other users (which we would expect given the volume of -proposed testing and the popularity of that particular X driver), I believe we should continue forward with this SRU for 8.04.1. Please keep your eyes open for any other signs of regression, but at this point it appears that the evolution slowdown is the worse bug that we should address.

Copied to hardy-updates.

Changed in cairo:
status: Fix Committed → Fix Released
beer (beer-test) wrote :

Evolution now scrolls somewhat faster, but the scrollbar now severely "lags", which means it is only updated with approx. 1 fps (so the email view scrolls but the scrollbar itself stays at the old position for some ms and then pops to the right place).
Plus I have the opposite behaviour of Gustavo Carneiro, gmail is NOW scrolling very slow, I believe it used to scroll fast before this update.
firefox seems to scroll a bit faster on other pages, though, but causes X to consume 50% cpu (this was the same before the update).

I tried to enable
    Option "AccelMethod" "XAA"
in the Section "Device" in xorg.conf, but it makes no difference, except for mplayer not running anymore.

I believe this whole issue might be related to bug


I reported earlier.

beer (beer-test) wrote :

PS: Can please someone confirm 100% cpu usage for Xorg with this google applet when rolling the eyes:


Colin Watson (cjwatson) wrote :

Fixed in Intrepid a while ago:

cairo (1.6.4-1ubuntu1) intrepid; urgency=low

  * Drop buggy_repeat band-aid now that xorg-server fixes the issue
    directly (LP: #186186)
  * Merge from debian unstable (1.6.4-1). Remaining ubuntu changes:
    - debian/control:
      - Maintainer: Ubuntu Core Developers <email address hidden>
      - Build-depends and Depends: libfontconfig1-dev >= 2.5.0-2ubuntu2 and
        libfreetype6-dev >= 2.3.5-1ubuntu4
    - debian/rules:
      - Pass -c4 to dpkg-gensymbols
    - debian/patches/02-lcd_filter_freedesktop_bug10301.dpatch

 -- Fabien Tassin <email address hidden> Fri, 09 May 2008 15:02:48 +0200

Changed in cairo:
status: Triaged → Fix Released
Steve Langasek (vorlon) wrote :

Hi Philipp,

Bug #232401 reports issues with high CPU usage in firefox, with versions of X prior to this recent update. While your scrolling problems may be related to bug #232401, this bug report doesn't appear to have much to do with that one.

Given the nature of this change, I don't see how it could have caused performance issues - it was the previous version of the package which was using the more resource-intensive routine. Could you please try downgrading to the version of libcairo2 from the hardy release (1.6.0-0ubuntu1) and restart your session, to confirm that this makes firefox faster for you?

I also experience the slow gmail scrolling.
But (@Steve):
I downgraded libcairo2 to hardy and that didn't change anything.
Looks like it's something else's fault.

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

Other bug subscribers