GNOME Bugzilla – Bug 306216
gtk+ CVS (Cairo) breaks desktop rendering in Nautilus.
Last modified: 2011-02-04 16:18:36 UTC
Please describe the problem: I installed glib, pango, and gtk+ from CVS today to see how Cairo is improving things and found that everything works fine except the nautilus-2.10.1 desktop has serious rendering problems with images being copied down and shifted up, really making it unusable. Steps to reproduce: Actual results: Expected results: Does this happen every time? Other information:
Created attachment 47124 [details] Problem Screenshot This came from opening, closing, and windows and dragging the desktop selector around.
Confirming so this shows up on more queries.
This is the same as bug 305459 - problem with pixbufs everywhere in gnome with gtk+ cvs (the same kind of corrupted images will also show up in the background chooser, drag-n-drop from the panel, etc)
BTW, to avoid the "screen replication" bug in nautilus, set the desktop background to a plain colour.
Vincent: while they are sort of similar issues, based on the information I've seen so far, I don't think they are the same bug. Debugging could prove that wrong, of course.
Created attachment 47805 [details] desktop corruption Hmmm. I didn't get this originally, but when i rebuilt and ran nautilus with an unrelated patch i suddenly got something that looks like this. Its not exactly identical though. See the attached image. Its clear that its reusing old non-cleared buffers when drawing. And as can be seen from the panel the chunks being reused are 256 pixels wide. Maybe that can help figuring out the cause.
The weird thing is that this bug only appears every other time. Right now I have a pixmap background in nautilus and it works just fine. If I switch to another background, or restart nautilus or the desktop, it will show the bug. Next time the bug might not show up, etc.
This looks like it might be an Xserver bug, related to Xrender vs tiled, large pixmaps. Turing off xrender in cairo makes it go away. Soeren came up with a test case which seems to indicate that it is related to the pixmap size exceeding 64k
Created attachment 47915 [details] soerens testcase
Xserver bug report and patch: https://bugs.freedesktop.org/show_bug.cgi?id=3566 Still have to figure out workarounds.
Cairo 0.5.1 will have a workaround, and the X server fix will hopefully make it in the next Xorg release, too. So lets close this bug.
There's a patch in Cairo CVS now that should be a workaround. I've tested with Soeren's test case and it fixes that, but never managed to reproduce the full nautilus problem. If people seeing that could test with CVS, that would be great.
I can verify that the nautilus issue is gone with cvs head of everything.
Same here.
the new cairo/gtk fixe the issue for me too
Me too.
The fix works for me when the XServer Composite Extention is disabled, but when I enable it, the problem resurfaces.
It won't work for X server snapshots, because my assumption is that the bug will get fixed before the next release. That's probably what you are seeing.
*** Bug 308963 has been marked as a duplicate of this bug. ***
So should we close this a NOTGNOME ?
*** Bug 312299 has been marked as a duplicate of this bug. ***
Hello, I'm still getting this with garnome-2.11.90 as well as the gnome-2.10 line. It happened on the stable branch when I went to gtk+-2.7.4/cairo. Moreover, it is happening in the garnome environment with gtk+-2.7.4 with cairo-0.6. I assumed that 0.6 would have had the necessary fixes to circumvent any Xserver issues. This is all on the xorg-x11-6.8.99.15 snapshot, which is from late July. The patch only made it in this week, so my Xserver is not patched. I realize that the issue is solved from most points of view, but is requiring the latest and greatest Xserver in the next release not a little worrisome to anyone?
The fix is used for X server <= 6.8.2, so the latest X server is not required. However a stable version of the X server is needed, which I think is reasonable.
I am still getting the bug with xorg-x11-8.9.99.15, gtk+-2.7.4, and cairo-0.6.0: 04:19:58 /home/Brian$ X -version This is a pre-release version of the The X.Org Foundation X11. It is not supported in any way. Bugs may be filed in the bugzilla at http://bugs.freedesktop.org/. Select the "xorg" product for bugs you find in this release. Before reporting bugs in pre-release versions please check the latest version in the The X.Org Foundation "monolithic tree" CVS repository hosted at http://www.freedesktop.org/Software/xorg/ X Window System Version 6.8.99.15 Release Date: 16 July 2005 + cvs X Protocol Version 11, Revision 0, Release 6.8.99.15 Build Operating System: Linux 2.6.11-gentoo-r9 i686 [ELF] Current Operating System: Linux olympus 2.6.11-gentoo-r9 #1 Sun Jun 5 14:32:13 MST 2005 i686 Build Date: 01 August 2005 Before reporting problems, check http://wiki.X.Org to make sure that you have the latest version. Module Loader present 04:20:00 /home/Brian$ pkg-config --modversion cairo 0.6.0 04:20:18 /home/Brian$ pkg-config --modversion gtk+-2.0 2.7.4
Brian: the code in Cairo assumes the bug is fixed in all xorg > 6.8.2; Older 6.8.99.x versions don't conform to this, but we don't want to do version checks on particular snapshots in the Cairo source code. if you update to a newer pre-release unsupported copy of Xorg, you'll be fine.
I'm afraid I'm still getting this problem, at least on the wallpaper. I just checked everything (including cairo, glitz) out with jhbuild. $ X -version X Window System Version 6.8.2 Release Date: 9 February 2005 X Protocol Version 11, Revision 0, Release 6.8.2 Build Operating System: Linux 2.6.11-gentoo-r3 i686 [ELF] Current Operating System: Linux tux 2.6.12-gentoo-r1 #1 SMP Sat Jun 25 22:27:07 BST 2005 i686 $ pkg-config --modversion cairo 0.6.0-head $ pkg-config --modversion gtk+-2.0 2.7.6 I'm using the radeon drivers and it doesn't happen on all wallpapers. I reported #312270 which shows my problem.. it seems to be the same bug as this, I just didn't find it in the search.
Applying Owen's patch to the X.org server fixed the issue for me. There are still issues when Nautilus tries to draw a background in any of its windows, but I don't feel that's related.
Cameron: You have a gentoo specific problem. For unknown reasons they changed their server vendor string. I've been told that a bug was filed against gentoo about this; they may want to submit a patch against Cairo so it can figure that they are really X.org despite not matching the server vendor string.
If Gentoo chooses to patch X, then they will probably be better off patching Cairo right at the ebuild. There is no reason why downstream brokenness should be fixed upstream. AFAIK, the reason they changed the vendor string is so that it stands out in the X log. In the past it was much easier to diagnose binary driver problems knowing right off the bat that the server could have been exposed to all sorts of USE flags.
I disagree, since it would break any application shipping cairo themselves.
*** Bug 312843 has been marked as a duplicate of this bug. ***
*** Bug 312968 has been marked as a duplicate of this bug. ***
The arguement of Gentoo changing the vender string is stupid. Cairo should be checking "X.Org version: 6.8.99.15" and not "vendor string: The X.Org Foundation" or "vendor release number: 60802000". Why? because these are meant to be modified by the vender, and the vender is the distro or the packager, not Xorg. And how do we know this? The new modular Xorg builds provide a ./configure command to change the vender information. The argument of "no other distro other then Gentoo does it" is incorrect since Cairo is checking the wrong field. Now if Cairo was checking the right field and Gentoo was messing with that field, then the argument might have a leg to stand upon. But because this field is MEANT to be changed by the packager/distro/end user means this is not the field to check against. It's just like the EXTRAVERSION field for the Linux kernel.
A vendor is a... vendor. Gentoo applies its own patchset and tells so in the vendor string. I filed the bug on gentoo bugzilla because it was meant against cairo-0.6.0. A version that was already released at that point of time and nothing can be done about it upstream, as it's released already. Hoped they'll file it upstream if deemed necessary (as I don't have much experience on judging what should go upstream and what not), but they haven't gotten around to that bug yet. The trivial patch is at https://bugs.gentoo.org/show_bug.cgi?id=100917#c1 I'll try to file it to freedesktop bugzilla too then under the existing bug https://bugs.freedesktop.org/show_bug.cgi?id=4068
I'm still seeing this bug with XFree86-4.5.0, gtk+-2.8.0, glib-2.8.0, pango-1.10.0, cairo-0.9.2 and nautilus-2.11.91
PLEASE DO NOT MAKE ADDITIONAL COMMENTS HERE ABOUT THIS PROBLEM. If you have a system that A) Is a real release build of X, not a devel snapshot B) Exhibits the problem Please create a new bug in bugs.freedesktop.org against Cairo and attach, as an attachment, the output of xdpyinfo. === Andrew: I've committed the following to Cairo CVS. 2005-08-20 Owen Taylor <otaylor@redhat.com> * src/cairo-xlib-surface.c (_cairo_xlib_surface_create_internal): Include Xfree86-4.5 in the blacklist. (Reported by Andrew Benton)
*** Bug 312270 has been marked as a duplicate of this bug. ***