Bug 4456 - Nautilus desktop incorrectly rendered with xaa acceleration
Nautilus desktop incorrectly rendered with xaa acceleration
Status: RESOLVED FIXED
Product: xorg
Classification: Unclassified
Component: Server/Acceleration/XAA
git
x86 (IA32) Linux (All)
: high major
Assigned To: ajax at nwnk dot net
Xorg Project Team
:
: 4431 5469 5733 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2005-09-14 19:55 UTC by Brian Beardall
Modified: 2007-07-26 18:30 UTC (History)
11 users (show)

See Also:
i915 platform:
i915 features:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Brian Beardall 2005-09-14 19:55:04 UTC
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.
Comment 1 Brian Beardall 2005-09-14 19:58:07 UTC
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
Comment 2 Federico Mena-Quintero 2005-09-15 11:59:06 UTC
See also bug #4320
Comment 3 Brian Beardall 2005-09-15 16:39:10 UTC
I am not sure what he means by saying acceleration doesn't work until running
glxinfo.
Comment 4 Frederic Crozat 2005-09-16 02:14:18 UTC
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.
Comment 5 Brian Beardall 2005-09-16 06:10:02 UTC
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.
Comment 6 Frederic Crozat 2005-09-16 06:19:47 UTC
No, I don't have any screen corruption. 
Comment 7 Brian Beardall 2005-09-16 06:49:02 UTC
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.
Comment 8 Brian Beardall 2005-09-18 11:22:12 UTC
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.
Comment 9 Brian Beardall 2005-09-20 22:20:32 UTC
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.
Comment 10 Brian Beardall 2005-09-20 22:50:02 UTC
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.
Comment 11 Brian Beardall 2005-09-21 21:19:03 UTC
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.
Comment 12 T. Hood 2005-09-23 09:06:06 UTC
*** Bug 4431 has been marked as a duplicate of this bug. ***
Comment 13 Brian Beardall 2005-09-23 10:54:20 UTC
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.
Comment 14 Brian Beardall 2005-09-23 13:53:20 UTC
Using the option 

Option "XaaNoOffscreenPixmaps" "yes"

is the temporary solution to the problem.
Comment 15 Eric Anholt 2005-09-30 18:19:05 UTC
Could the submitter try with current cairo bits, which should fix this issue?
Comment 16 Nicolas Mailhot 2005-10-01 02:13:34 UTC
Is this current enough ?

cairo-1.0.0-1
xorg-x11-6.8.99.14-3
Comment 17 Brian Beardall 2005-10-01 09:37:41 UTC
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.
Comment 18 Brian Beardall 2005-10-01 09:43:49 UTC
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
Comment 19 Benjamin Herrenschmidt 2005-10-02 22:46:56 UTC
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"
Comment 20 Brian Beardall 2005-10-03 05:21:16 UTC
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.
Comment 21 Brian Beardall 2005-10-06 07:13:34 UTC
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.
Comment 22 Brian Beardall 2005-10-06 09:37:57 UTC
Update your cairo to 1.0.2 and the bug is fixed.  Have a nice day.
Comment 23 Benjamin Herrenschmidt 2005-10-06 14:00:09 UTC
Not fixed, I had the bug with Cairo 1.0.3
Comment 24 Benjamin Herrenschmidt 2005-10-06 14:01:20 UTC
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.
Comment 25 Brian Beardall 2005-10-06 17:18:55 UTC
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.
Comment 26 Benjamin Herrenschmidt 2005-10-06 17:40:41 UTC
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.
Comment 27 Benjamin Herrenschmidt 2005-10-06 17:48:18 UTC
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.
Comment 28 Brian Beardall 2005-10-06 19:15:04 UTC
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.
Comment 29 Nicolas Mailhot 2005-10-08 06:21:48 UTC
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
Comment 30 Brian Beardall 2005-10-08 07:54:01 UTC
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.
Comment 31 Nicolas Mailhot 2005-10-08 08:38:02 UTC
(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)
Comment 32 Benjamin Herrenschmidt 2005-10-09 15:30:04 UTC
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.
Comment 33 Brian Beardall 2005-10-10 20:20:32 UTC
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.
Comment 34 Brian Beardall 2005-11-14 16:48:22 UTC
The bug is back in Xorg 7.0 RC2. :(  All of the same symptoms exist.
Comment 35 Benjamin Herrenschmidt 2005-11-14 16:55:34 UTC
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
Comment 36 Frank Arnold 2005-11-30 05:49:43 UTC
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
Comment 37 Brian Beardall 2005-12-18 18:21:42 UTC
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.
Comment 38 ajax at nwnk dot net 2006-01-04 10:43:06 UTC
*** Bug 5469 has been marked as a duplicate of this bug. ***
Comment 39 ajax at nwnk dot net 2006-01-04 10:44:44 UTC
taking
Comment 40 Michel Dänzer 2006-01-23 21:47:38 UTC
This bug seems to be in XAA as opposed to a driver, reassigning.
Comment 41 Michel Dänzer 2006-01-26 18:27:03 UTC
*** Bug 5733 has been marked as a duplicate of this bug. ***
Comment 42 ajax at nwnk dot net 2006-02-14 18:40:51 UTC
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.
Comment 43 Michel Dänzer 2006-02-14 23:19:07 UTC
Ï 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...
Comment 44 Frank Arnold 2006-02-14 23:47:52 UTC
Fedora Rawhide doesn't show this problem anymore:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=178433
Comment 45 Michel Dänzer 2006-02-15 00:36:01 UTC
(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? :)
Comment 46 Dave Jones 2006-02-15 05:52:20 UTC
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.
Comment 47 Brian Beardall 2006-02-15 12:59:57 UTC
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.
Comment 48 Brian Beardall 2006-02-15 14:59:57 UTC
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.
Comment 49 Brian Beardall 2006-02-15 15:18:30 UTC
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.

Comment 50 Brian Beardall 2006-02-16 01:11:17 UTC
I've never experience the slowdown mentioned in bug 4320, and running glxgears
never fixed anything for me.
Comment 51 Michel Dänzer 2006-02-16 02:26:57 UTC
(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.
Comment 52 Diffie 2006-02-16 05:47:17 UTC
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.
Comment 53 Erik Andren 2006-06-03 08:41:06 UTC
Is someone still experiencing this bug using an up-to-date version of xorg with
friends?
Comment 54 Dave Jones 2006-06-03 10:15:12 UTC
was fixed for me in one of the Fedora rawhide updates from a few weeks ago.
Comment 55 Daniel Stone 2007-02-27 01:27:59 UTC
Sorry about the phenomenal bug spam, guys.  Adding xorg-team@ to the QA contact so bugs don't get lost in future.
Comment 56 Dave Airlie 2007-07-26 18:30:26 UTC
looks fixed.