After a fresh F14 installation, the Gnome-Do window on my system has some rendering issues not found in my F13 install, and behaves extremely slow. Similar rendering glitches are visible in the 'selected' application buttons in the default panel at the bottom of the GNOME desktop, as well as the background of GTK+ scrollbars using the default theme. This seems to be related to gradient handling in Cairo. I rebuilt Cairo using the patch found at [1], and restarted Gnome-Do to use this library (didn't install it system-wide, so didn't validate this would fix the panel buttons or scrollbars). Using the new version of the library (libcairo.so.2.11000.0, as validated through lsof), the Gnome-Do window no longer shows these rendering bugs, and no longer behaves extremely slow (but snappy again, as it should). For reference: $ rpm -q cairo xorg-x11-drv-nvidia xorg-x11-server-Xorg cairo-1.10.0-1.fc14.x86_64 cairo-1.10.0-1.fc14.i686 xorg-x11-drv-nvidia-260.19.12-3.fc14.x86_64 xorg-x11-server-Xorg-1.9.1-2.fc14.x86_64 [1] http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/x11-libs/cairo/files/cairo-1.10.0-buggy_gradients.patch?revision=1.2
This problem affects many applications making them almost unusably slow on f14. gitg and gnomine are good examples. Firefox seems to be affected too. I applied the patch above and replaced the system cairo package and all of these applications now run smoothly. I am using the nvidia binary driver.
Temporary solution echo " [fedora13] name=Fedora 13 - $basearch failovermethod=priority baseurl=http://download.fedoraproject.org/pub/fedora/linux/releases/13/Everything/$basearch/os/ enabled=0 metadata_expire=7d gpgcheck=1 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-$basearch [f13-updates] name=Fedora 13 - $basearch - Updates failovermethod=priority baseurl=http://mirror.bytemark.co.uk/fedora/linux/updates/13/$basearch/ enabled=0 gpgcheck=1 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-$basearch " > /etc/yum.repos.d/fedora-13.repo yum --nogpgcheck --noplugins --disablerepo=* --enablerepo=fedora13 downgrade cairo.x86_64 cairomm.x86_64 cairo-devel.x86_64
*** Bug 650718 has been marked as a duplicate of this bug. ***
*** Bug 652282 has been marked as a duplicate of this bug. ***
*** Bug 652124 has been marked as a duplicate of this bug. ***
Meanwhile you can keep track of http://pkgs.fedoraproject.org/gitweb/?p=cairo.git and use a working patched cairo package: http://www.nvnews.net/vbulletin/showpost.php?p=2345813&postcount=8
I have the same issue on Fedora 14 x86_64. I am using the proprietary nVidia drivers. Another work around I've found works for me is to change the GNOME theme from the default "Fedora" theme to the "Mist" theme (others may work also). My GNOME session was unbearably sluggish but this seems to have (temporarily) corrected it.
It's ugly workaround. Only correct working simplest theme.
(In reply to comment #2) > Temporary solution > > echo " > [fedora13] > name=Fedora 13 - $basearch > failovermethod=priority > baseurl=http://download.fedoraproject.org/pub/fedora/linux/releases/13/Everything/$basearch/os/ > enabled=0 > metadata_expire=7d > gpgcheck=1 > gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-$basearch > > [f13-updates] > name=Fedora 13 - $basearch - Updates > failovermethod=priority > baseurl=http://mirror.bytemark.co.uk/fedora/linux/updates/13/$basearch/ > enabled=0 > gpgcheck=1 > gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-$basearch > " > /etc/yum.repos.d/fedora-13.repo > > yum --nogpgcheck --noplugins --disablerepo=* --enablerepo=fedora13 downgrade > cairo.x86_64 cairomm.x86_64 cairo-devel.x86_64 Thank you, this allowed my nvidia driver to work and not lag like crazy when i switched desktops/windows. Wow it's snappy again. Thank god. Also, I ran into one issue, if you echo with double quotes " " I think it expanded the $basearch (in this case to nothing) and i ended up with nothing between two // inside the repo file, quick manual edit fixed it but for others I think if you do echo ' man 1 bash === Enclosing characters in single quotes preserves the literal value of each character within the quotes. A single quote may not occur between single quotes, even when preceded by a backslash. Enclosing characters in double quotes preserves the literal value of all characters within the quotes, with the exception of $, `, \, and, when history expansion is enabled, !. The characters $ and ` retain their special meaning within double quotes. The backslash retains its special meaning only when followed by one of the following characters: $, `, ", \, or <newline>. A double quote may be quoted within double quotes by preceding it with a backslash. If enabled, history expansion will be performed unless an ! appearing in double quotes is escaped using a backslash. The backslash preceding the ! is not removed. === So I think what you want for the echo command is echo ' [fedora13] name=Fedora 13 - $basearch failovermethod=priority baseurl=http://download.fedoraproject.org/pub/fedora/linux/releases/13/Everything/$basearch/os/ enabled=0 metadata_expire=7d gpgcheck=1 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-$basearch [f13-updates] name=Fedora 13 - $basearch - Updates failovermethod=priority baseurl=http://mirror.bytemark.co.uk/fedora/linux/updates/13/$basearch/ enabled=0 gpgcheck=1 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-$basearch ' > /etc/yum.repos.d/fedora-13.repo then yum --nogpgcheck --noplugins --disablerepo=* --enablerepo=fedora13 downgrade cairo.x86_64 cairomm.x86_64 cairo-devel.x86_64 Thanks again
You may want to exclude cairo and cairomm from being updated by yum, add this to /etc/yum.conf exclude=cairo* cairomm*
Cairo guys won't fix it. But could we get a temporary fix unless nvidia fix it?
FYI, I have opened a ticket[1] with NVIDIA. [1] http://www.nvnews.net/vbulletin/showthread.php?t=157352
The patch that Artem post is working. Do you check it?
The patch works for me.
It seems that downgrading cairo packages breaks down the PDF support in evince. I think the best temporary solution is to install cairo packages from Russian Fedora repos. http://tigro.info/wp/?p=483
*** Bug 660353 has been marked as a duplicate of this bug. ***
I just spent some time on this. I tried the latest driver from nvidia, 260.19.21, but that didn't resolve this problem. I then performed what was recommended in comment #9 and comment #10. The issue with the brokeness of the nvidia driver went away. as for the pdf problem, my work around was to install acroread. This problem is really nasty in my view...
I'm also experiencing this issue... _very_ annoying. 260.19.26 doesn't help.
I didn't perform downgrade, just applied the patch to the current version of cairo and rebuilt it. I would like to know the maintainer's opinion, why don't you apply the patch to updates-testing and watch for the carma?
(In reply to comment #19) > I didn't perform downgrade, just applied the patch to the current version of > cairo and rebuilt it. I would like to know the maintainer's opinion, why don't > you apply the patch to updates-testing and watch for the carma? Fedora official stance and policy is not to really care about users who use proprietary drivers. So, this bug report can have two resolutions: NVIDIA fixes it (and it seems like they are not particularly interested) or cairo maintainers introduce a fix (or rather revert the changes) for NVIDIA drivers. However in the latter case the issue will be fixed only in Fedora 15 which is 5 months due. Meanwhile you can *compile* a working cairo package from here: http://www.nvnews.net/vbulletin/showpost.php?p=2345813&postcount=8 (this src.rpm contains the only change - a patch from Arch, no other changes have been introduced).
(In reply to comment #20) > (In reply to comment #19) > > I didn't perform downgrade, just applied the patch to the current version of > > cairo and rebuilt it. I would like to know the maintainer's opinion, why don't > > you apply the patch to updates-testing and watch for the carma? > > Fedora official stance and policy is not to really care about users who use > proprietary drivers. So how are NVIDIA users supposed to get 3D support? You don't care about not providing basic functionality? And if Fedora doesn't care about proprietary stuff, why was so much invested on automatic codec install so that it's easy to install Fluendo codecs? Doesn't make sense.
(In reply to comment #21) > So how are NVIDIA users supposed to get 3D support? You don't care about not > providing basic functionality? Ask NVIDIA to release the source.
(In reply to comment #22) > (In reply to comment #21) > > So how are NVIDIA users supposed to get 3D support? You don't care about not > > providing basic functionality? > > Ask NVIDIA to release the source. Such a typical answer.
(In reply to comment #23) > (In reply to comment #22) > > (In reply to comment #21) > > > So how are NVIDIA users supposed to get 3D support? You don't care about not > > > providing basic functionality? > > > > Ask NVIDIA to release the source. > > Such a typical answer. Please note that the people responding here are not talking on behalf of the Fedora project, their comments are just their 2 cents. Although as a policy Fedora does not support non open source drivers. Fedora also tends to not deliberately break them / make live for users of them extra hard. Regards, Hans (who is also not speaking on behalf of the Fedora project)
So why isn't this bug closed then? Can someone clarify something for me? Is this bug due to the NVIDIA proprietary driver only? NVIDIA came out with a new driver 260.19.29. Does this new driver fix the problem?
So, after discussing this with various people, I decided to take the following approach: 1) I'll fix this for F14 (or better: Hans volunteered to) 2) rawhide will not get the fix. 3) F15 is very unlikely to get the fix. This gives nVidia another 5 or so months to fix their broken driver.
If and when NVIDIA fixes their driver, what should we be looking for to know they fixed it? What specific aspect of the NVIDIA driver should we tell them needs fixing? I'll be glad to issue another bug report to NVIDIA.
(In reply to comment #21) > So how are NVIDIA users supposed to get 3D support? You don't care about not > providing basic functionality? > NVIDIA users are supposed to get 3D support by buying ATI hardware instead. I'm pretty sure you knew before you even bought it that you'd have to fall back to unsupported software with that hardware. So it's completely your own fault if 3D doesn't work. > And if Fedora doesn't care about proprietary stuff, why was so much invested on > automatic codec install so that it's easy to install Fluendo codecs? > Yeah, that was stupid. We still have to fix the fallout from: All the bugs that are usually solved by "please uninstall the Fluendo software". And I'm pretty sure we've learned from that experience. Also, I wasn't involved in that stuff back then. And we all know: New people, new rules. And in case that isn't well-known: I'm a pretty hardcore Free Software person.
cairo-1.10.0-2.fc14.1 has been submitted as an update for Fedora 14. https://admin.fedoraproject.org/updates/cairo-1.10.0-2.fc14.1
I'm very happy to see this bug fixed in cairo, it makes my job much easier. As much as I respect Benjamin Otte's FOSS ideals, the reality is that any serious 3d work on linux requires nVidia and their proprietary drivers. Have a look at these recent benchmarks to see why the ATI FOSS driver isn't much good: http://www.phoronix.com/scan.php?page=article&item=amd_r600g_q410
My thought on the entire permanent fix. Let's leave the politics at the door and get this fixed in the proper place. I don't know anything about cairo so is the problem a bug in cairo or a how NVidia uses it. If it's a Nvidia problem let's all offer our services to NVidia and get a group bug going. I'll be a beta tester if needed. Let's just fix the problem. Fedora stands for freedom so we should be putting shackles on to only use open-source.
(In reply to comment #28) > (In reply to comment #21) > > So how are NVIDIA users supposed to get 3D support? You don't care about not > > providing basic functionality? > > > NVIDIA users are supposed to get 3D support by buying ATI hardware instead. I'm > pretty sure you knew before you even bought it that you'd have to fall back to > unsupported software with that hardware. So it's completely your own fault if > 3D doesn't work. That's the laptop I get from my employer. Feel free to send me a quad-core Intel i7 laptop with an ATI card, I would then gladly use the radeon driver and even compile it myself as often as I can. Meanwhile, in the real world, I'm just glad I'm able to play Starcraft 2 on my linux laptop and 2D operations are not dead slow.
(In reply to comment #31) > My thought on the entire permanent fix. Let's leave the politics at the door > and get this fixed in the proper place. I don't know anything about cairo so > is the problem a bug in cairo or a how NVidia uses it. If it's a Nvidia > problem let's all offer our services to NVidia and get a group bug going. I'll > be a beta tester if needed. Let's just fix the problem. > > Fedora stands for freedom so we should be putting shackles on to only use > open-source. The problem is in the NVIDIA driver, however, you can say that cairo 1.10 is breaking API, so it's not surprising that some period of adjustment is needed. The latest candidate driver, 260.19.29, doesn't fix the issue, however, I heard in #nvidia IRC channel that this bug has been fixed, but it's not on any release yet. So it would probably take a while.
cairo-1.10.0-2.fc14.1 has been pushed to the Fedora 14 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update cairo'. You can provide feedback for this update here: https://admin.fedoraproject.org/updates/cairo-1.10.0-2.fc14.1
*** Bug 657597 has been marked as a duplicate of this bug. ***
I ran into problems opening PDF files in evince after downgrading cairo to the version in f13 Similar to this report http://forums.fedoraforum.org/showthread.php?t=253252 "File type PDF document (application/pdf) is not supported" Upgrading to the normal version of Cairo in F14 fixed that issue. I'm going to try the test version of Cairo mentioned in comment 34 now.
cairo-1.10.0-2.fc14.1 has been pushed to the Fedora 14 stable repository. If problems still persist, please make note of it in this bug report.
I can confirm that the fix works.
Now that the issue has been resolved with a push of the latest cairo package, can someone describe how to undo the fedora 13 patch described in comments #2 and #9? Thanks.
easy: remove cairo from your "exclude"-setting in /etc/yum.conf (https://bugzilla.redhat.com/show_bug.cgi?id=649955#c10) run "yum update".
I`m using latest cairo packages cairo-1.10.0-2.fc14.1.x86_64 cairo-1.10.0-2.fc14.1.i686 cairo-devel-1.10.0-2.fc14.1.x86_64 cairo-devel-1.10.0-2.fc14.1.i686 and Latest nvidia drivers 260.19.29. When using multi-tab browsers apps like opera chrome..etc xorg uses too much cpu %50-90 and switching windows very very slow. I can confirm still something cause slow xorg...
I cannot confirm this. I'm using the same versions of cairo and nvidia. I tried with chromium (9.0.600.0) and Firefox (3.6.13). I use gnome+compiz+emerald. I have the window-switcher plugin enabled, so compiz takes care of stuff. For me the latest cairo update resolved the described performance-issue.
It can be caused by a certain gnome theme. Which one do you use? I also think there's still something rotten in xorg although the main problem has been solved. I have a problem with switching to a workspace where gnome-terminal is open and maximized.
I dont use gnome.. KDE only.. and I switched transparent grey theme.. still slow.. I`m using browsers with lots of tabs opened for example 15-20 at the same time.. and other app editors..etc switching apps and windows very very slow and annoying.. Xorg uses %20-40+ and more in 2-3 second delay.. also flash video`s cant go fullscreen. VLC cant render video in default settings.. desktop-effects not working.. all disabled..
I have rendering issue with equinox gtk theme, context menu are ugly with no border and background is messed.
I am having some severe speed issues and I think it may be related to this bug rearing its' ugly head again. Some Info: NVIDIA 260.19.36 cairo-1.10.2-1.fc14.x86_64 cairomm-1.9.2-1.fc14.x86_64 I originally replaced the F14 cairo with the one from F13 as mentioned above. This significantly improved speed but caused some issues with the long-term stability of my system. After reading this bug report I upgraded to the fixed version of cairo from F14. I am having some major issues with the speed of nautilus. It is especially slow when opening a drive which needs to be mounted prior to browsing. It takes at least 30 seconds to open the drive partition. I installed Thunar to ensure that it is not my machine acting up. Thunar is quick and light and changes directories at the speed I would expect of nautilus.
FYI: NVIDIA driver version 270.41.03 fixed the gradient issue. The patch can now be removed.