03-turn_on_buggy-repeat_handling.dpatch causes slowdown in Evolution

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?

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.

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

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

s/-updates/-proposed/

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

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

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

Accepted into -proposed, please test and give feedback here

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.

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.

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

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.

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.

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

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

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

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

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

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

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.

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

https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/232401

I reported earlier.

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

http://www.google.de/ig/adde?hl=de&moduleurl=eyes.xml&source=imag

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

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.