Distribution: Gentoo Base System version 1.6.13 Package: nautilus Severity: Normal Version: GNOME2.12.0 unspecified Gnome-Distributor: Gentoo Synopsis: Gnome 2.12 background doesn't draw correctly Bugzilla-Product: nautilus Bugzilla-Component: Desktop Bugzilla-Version: unspecified Description: Description of Problem: Nautilus can't draw the desktop correctly when I select to have a gradient for the color or when I select a picture for the desktop background. I have the complete install of Gnome 2.12, and I would like to have my desktop working. I thought that it was related to bug http://bugzilla.gnome.org/show_bug.cgi?id=306216 but it is not completely the same. I am running Xorg 7 CVS snapshot September 9 2005. I read that the bug had been fixed in X so perhaps it is a bug in Nautilus. Owen Taylor had some patches that he wrote but they don't work. I forced the redraw work around in Cairo, but that didn't completely fix the bug. It partially fixed the desktop issue by forcing the redraw bug. With the work around I was able to correctly have a desktop background tiled, but any other option caused the desktop to repeat itself. I reverted back to without my patch. I checked to see if what Owen Taylor had done for the bug had done anything so I ran a diff on fbpict.c from CVS, and what Gentoo was installing, and the files are exactly the same. I am the ATI drivers from the X.org project. I would like my desktop to look a lot better. I have a link to a screenshot. http://rapsure.net/Screenshot.png There you will see what I am seeing. I ran the test case from http://bugzilla.gnome.org/show_bug.cgi?id=306216 and the test case passed. There were no repeat problems. Nautilus still won't draw the desktop correct with graphics or color gradients. My Graphics card is a ATI Radeon 9000. Hence I am using the radeon driver in X.org X11. I think it is in the radeon driver. When I disable acceleration the desktop draws correctly, but when I enable acceleration the desktop becomes looks the same as in the screenshot. I tried out the vesa driver and the desktop displayed correctly also. So I believe it is the acceleration for the ATI Radeon 9000 card that is causing this problem. There is no desktop render issue when acceleration is disabled in the xorg.conf file.
This seems to have become a problem since GTK+ moved to using the cairo library for rendering. This also occurred in X.org 6.8.99.15
See also bug #4320
I am not sure what he means by saying acceleration doesn't work until running glxinfo.
I think I was quite clear : XRenderComposite is slow as hell until glxinfo is started. Rendering speed can also come back to life when changing background size of nautilus. There are several issues with XRenderComposite and I'm not 100% sure it is a Radeon driver issue : we have seen slow rendering with Radeon, Nvidia (both proprietary and opensource) and matrox card. "Running glxinfo" trick is only working on Radeon. In any case, forcing cairo to use XCopyArea instead of XRenderComposite hides the slow refresh.
I see what you are talking about. It is extremely at redrawing when moving the windows around. Even slower when I attempt to set a background image, but running glxinfo doesn't speed up the redrawing though. I am curious if your desktop is messing up like mine is in the screenshot.
No, I don't have any screen corruption.
It looks like this screen corruption bug is very specific to the Radeon 9000, and the use of cairo to draw the background. I've seen the screen corruption in more than just the gnome desktop though. Like tuxracer has a big + drawn in the screen at startup, and descent 2 has the menu completely corrupted. This bug does not exist in ATI's closed source release.
I did some testing. These are the results along with test images. This bug only occurs when the total number of pixels in an image are greater or equal to 64000. That is >= 64000. So This only works with tiling the image because then there is no preprocessing of the image to make it be in the center, or to scale the image. Here are links to the test images. http://rapsure.net/IM001654-bad.png Causes desktop corruption problem. http://rapsure.net/IM001654.png This works just fine. http://rapsure.net/cow-trans.png This is the cow-trans.png from the gnome project to fit within the indicated value of less than 64000 pixels. http://rapsure.net/cow-trans-bad.png The cow image at 64009 pixels total. Causes desktop corruption. http://rapsure.net/test.png This is IM001654 resized to be 63993 pixels. I wanted to know if the total kilobytes of the file made a difference to whether or not it would cause the desktop corruption but the kilobyte size of the file made no difference. The file could 150K or 10K and the image worked. What was constant was the number of pixels in the image causing the desktop corruption. Because the number is so close to the 16bit value I am thinking that this is a buffer over flow. The memory that has been allocated 2^16, but when a higher number of pixels are shown then it causes the buffer to overflow into the memory location that is drawing the windows.
I am not using the XRenderComposite (XComposite) extension. I don't have any problems with acceleration because I am not using the composite extension. This is a fully accelerated desktop with XAA. From my understanding is that because I the composite extenstion installed, but not enabled in xorg.conf then Cairo should use the XCopyArea to render the desktop. Correct me if I am wrong. EXA acceleration doesn't work yet for me.
Ok this is not a composite bug at all. I tested and yes when using composite you will experience bug 4320, but when not using composite I experience this bug. My desktop is not using composite. I just tried out composite and so I know.
The default depth for the radeon driver is 16 bit unless other wise set. When using 16 bit depth the desktop renders perfectly, but any other depth has desktop corruption when selecting an image. For those who have not changed the color depth will not experience any desktop corruption. This is assuming that all other graphic settings are at their default.
*** Bug 4431 has been marked as a duplicate of this bug. ***
This is a radeon specific issue. This does not occur on other drivers. I tested on a Pentium 4 with a Radeon 7000 and this problem occurs. From what I can tell this is only occuring with the CVS head. There was another bug with desktop corruption in the past, but this one deals with the Radeon driver specifically.
Using the option Option "XaaNoOffscreenPixmaps" "yes" is the temporary solution to the problem.
Could the submitter try with current cairo bits, which should fix this issue?
Is this current enough ? cairo-1.0.0-1 xorg-x11-6.8.99.14-3
I synced with CVS to get the latest ati drivers changes in the radeon driver. I am not quite sure what you mean about the "cairo bits". If I didn't do quite what you want could you explain a little more about what you mean by "cairo bits" The latest test results with the newest CVS snapshot of the ATI driver is that the bug is still present. Still the same result occurs.
Here are the versions I am running of some of the different packages: GTK+ 2.8.4 Cairo 1.0.0 Gnome 2.12.0 eel 2.12.0 pango 2.10.0
Happens here too with current CVS and userland either up to date from debian sid with experimental bits, or ubuntu breezy. However, I also reproduced it with the free "nv" driver on a 5200FX, so I don't think it's a driver specific thing. I haven't yet tried Option "XaaNoOffscreenPixmaps" "yes"
I looks like I will need to test with the nv driver next. I have tested with the vesa driver, and i810 driver, and there is no rendering problem with either of those drivers. I tried the livecd of Ubuntu 5.10, and there wasn't a desktop problem. I also tried the Gnome 2.12.0 livecd, and there was no desktop corruption there also, but there is a work around implemented in the cairo library for Xorg 6.8.2. I enabled the work around for the cairo library by setting the default boolean value from false to true, but this bug still showed. I have tried some of the experimental backends for cairo, but the desktop still doesn't render correctly unless Option "XaaNoOffscreenPixmaps" "yes" is used.
I am unable to create this bug. Please update to cairo 1.0.2, and pango 1.10.1. I just want to know if that is where it got fixed, or if it was fixed in xorg-server. I know that a patch was added for a transparency fix in xorg-server in Gentoo, but I am not sure that fixed it. I just know that it is fixed in Gentoo. I see that this bug also occured in other distros tho so I am assuming it wasn't just Gentoo. If no responses in 12 hours I will close this bug with code fix in Cairo.
Update your cairo to 1.0.2 and the bug is fixed. Have a nice day.
Not fixed, I had the bug with Cairo 1.0.3
More precisely... gtk2.8 and X.org from CVS . It works with X.org 6.8.2, apparently thanks to the "workaround" in Cairo that tests the X.org version. That makes me think that the bug that was supposedly fixed in X.org may not have been.
Hmmm. I did the same operation on two computers that exibited this bug, and simply by updating cairo from 1.0.0 to 1.0.2 fixed the display problem. Then again they are both using ATI Radeon cards. To test for this bug you will need a CVS snapshot newer than Xorg 7.0RC0. Xorg 6.8.99.15 < is not new enough. Don't use any patches with the cairo 1.0.2. Benjamin I would like to know more about your setup so that perhaps I can recreate the occurance of this bug.
I've reproduced that on 2 machines, both running the same X.org from CVS of about a week or 2 ago (I'll re-test with a snapshot from today later today or tomorrow). One is an Apple Titanium PowerBook with a Radeon M9 (r9000 mobility, rv250), the other is an Apple iMac G5 ("nv" driver on nVidia 5200FX, 64 bits kernel, 32 bits X server & userland). The first one is running debian sid, the second one is running ubuntu breezy. HOWEVER, I just noticed my mistake here, that is that libcairo on the debian box is 1.0.0-3 (and not 1.0.3 or whatever). Which means you might actually have been right all along. I noticed that the breezy box just got a libcairo-1.0.2 update. I'll test again on that one and will let you know in a few minutes.
Ok, there is a difference, but the problem isn't fixed (unless some other problem is beeing triggered by X.org CVS on this machine). So basically, the desktop is correctly rendered, the menubar is no longer rendered half way through the backround, etc... However, opening a terminal and quickly moving it around shows bits & pieces of that terminal window sticking here or there on the desktop (it's not properly refreshing all damaged regions). It's even easier to reproduce by clicking into the background to get the translucent selection rectangle. That one never gets erased at all. Finally, a question: Did libcairo 1.0.2 actually fixed a bug or did it just bring in the workaround that it had for X.org 6.8.2 and applied it to X.org 6.9/7 ? In the later case, that means we still have an X.org bug to fix in which case I'd be interested in the details. On the other machine (with the radeon), I don't yet have libcairo 1.0.2 to test with as it's not yet in sid nor in experimental. I'll eventually try to rebuild myself from CVS once i get a bit more time and will let you know.
I'll check the cairo library because I have looked at the work around. Even though the work around only partially worked at that. I do highly doubt that cairo put the work around in cairo because the cairo developers attitude was such that the X.org devs should fix this bug.
On this system (Fedora Devel aka Raw Hide) the cairo update by itself is not fixing the problem. I suppose the fix is some xorg-x11/cairo combo ? What are the minimal versions needed ? I have : cairo-1.0.2-1 xorg-x11-6.8.99.14-3
Nicolas, you need to get a newer CVS snapshot. You need a newer snapshot than September 1st. Benjamin I checked to see if the work around was being used in CVS Xorg, but it should be enabled. surface->buggy_repeat is only true when running a version of Xorg older than or equal to xorg 6.8.2, and xfree 4.4. The work around is in the file cairo-xlib-surface.c if you want to look at it your self.
(In reply to comment #30) > Nicolas, you need to get a newer CVS snapshot. You need a newer snapshot than > September 1st. Ok, this is as I suspected. Unless Mike A. Harris does another monolithic build I'll have to wait for his modular packaging to be ready (I probably would not even have touched the snapshot in the first place if the official Raw Hide release had been supporting my chipset properly)
I confirm here, bug is still here on rv280, x.org CVS from a couple of days ago, libcairo2-1.0.2-0ubuntu1 using XAA (not using EXA though). Looks like an XAA bug or maybe a problem with the radeon driver XAA accel code.
Benjamin, I would like a copy of the source that the cairo you are using has been compiled with. Either that or point me to where I can get it.
The bug is back in Xorg 7.0 RC2. :( All of the same symptoms exist.
I suspect the problem I had on the iMac G5 were related to the changes to the "nv" driver in the EXA "nv" patch breaking XAA. That patch has NOT been merged though. So far, I have no problem with EXA and current debian on my laptop with what is an almost-RC2 tree. I'll try building -RC2 later this week and test it on a variety of boxes I have around to let you know what happens
I see this too on an Aluminum PowerBook5,6 with Fedora Rawhide. Detected chipset: Radeon Mobility 9600/9700 (M10/M11) NP (AGP) Package versions: xorg-x11 7.0.0 RC2 nautilus-2.12.1-6 cairo-1.0.2-3
I now have X.org 7.0 RC4. The bug is still present with XAA acceleration, but not with EXA acceleration. XAA acceleration is broke in more places also because I have other programs that aren't accelerated with XAA like missile command, and sopwith. EXA acceleration seems to be more stable now than the XAA counterpart. To avoid this bug use EXA acceleration.
*** Bug 5469 has been marked as a duplicate of this bug. ***
taking
This bug seems to be in XAA as opposed to a driver, reassigning.
*** Bug 5733 has been marked as a duplicate of this bug. ***
Michel, do you have an idea where we're going wrong with this? I suspect it's something like not accounting for pixmap x/y everywhere we need to, but I'm not clear what would have introduced that change.
Ï was about to ask the same thing. :} My first guess would be that the EXA integration accidentally broke XAA slightly, but I just remembered bug 3566; maybe it's a similar bug that Cairo just happens to work around with older X servers? This is creating quite a support headache at least in Debian, any clues would be much appreciated...
Fedora Rawhide doesn't show this problem anymore: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=178433
(In reply to comment #44) > Fedora Rawhide doesn't show this problem anymore: > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=178433 Mike, how did you fix this? :)
the problem is still very much there for me with latest rawhide on an rv370. (X300SE) it's very easy to trigger, by just starting firefox, and browsing for five minutes. It's not long before bits of the window start getting blue rectangles splatted over it. When I quit the browser, I'm left with a same blue sqaure on the desktop where the browser used to be. drag-select 'eats' the dead pixels. Sometimes, scrolling in the browser makes the problem go away. Sometimes, it makes it a lot worse, making it render an enormous rectangle over the entire desktop.
As mysterious as this bug is, it has gone away for the second time for me since September in Gentoo. I believe it is a recent update that I did, and I have two other computers that I can find which patch has caused the desktop corruption to clear up.
I have been able to fix the bug with updating gtk+ to version 2.8.12. The updated of gtk+ fixed two of my computers. I don't know if that will fix it for anyone else. A -O3 has been reported to break video cards because of -fweb.
Changelog about a bug that from reading seems to be related. Reading through the bug report it seems like nautilus was redrawing the desktop, but not clearing correctly. A workaround to me. Specific for the radeon driver. 2006-02-03 Federico Mena Quintero <federico@ximian.com> Merged from HEAD: Work around https://bugs.freedesktop.org/show_bug.cgi?id=4320, which used to be our own http://bugzilla.gnome.org/show_bug.cgi?id=314616. If one uses a pixmap for a pattern in Cairo, and sets the pattern to CAIRO_EXTEND_REPEAT; and if the destination surface is also a pixmap, Cairo does a slow copy instead of using XCopyArea(). So, we use the same code that we used in GTK+ 2.6 (pre-cairo), by filling the double-buffer pixmap with a tiled GC and XFillRectangle(). * gdk/gdkwindow.c (BackingRectMethod): New structure with a cairo_t and a GdkGC field. Depending on which of these fields gets filled in, we'll use Cairo or GDK to clear the double-buffer pixmap when painting a window. (setup_backing_rect_method): Fill a BackingRectMethod as appropriate, depending on the window's configuration and our knowledge of whether Cairo is fast or slow when doing repeating patterns. (gdk_window_clear_backing_rect): Call setup_backing_rect_method(). Depending on what it returns, use Cairo to clear the double-buffer pixmap, or plain GDK.
I've never experience the slowdown mentioned in bug 4320, and running glxgears never fixed anything for me.
(In reply to comment #49) > A workaround to me. Indeed, as the changelog says. > Specific for the radeon driver. How so? The other bug seems to be in XAA, just like this one. I doubt they're the same, but I agree that the workaround for the other bug is probably the reason why GTK+ 2.8.12 happens to avoid this one as well.
I just verified that after upgrading to gtk+2-2.8.12 release and removing the Option "XaaNoOffscreenPixmaps" "yes" from xorg.conf file as seen in comment #14 fixes the desktop blurring issues on Radeon Mobility 7500.
Is someone still experiencing this bug using an up-to-date version of xorg with friends?
was fixed for me in one of the Fedora rawhide updates from a few weeks ago.
Sorry about the phenomenal bug spam, guys. Adding xorg-team@ to the QA contact so bugs don't get lost in future.
looks fixed.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.