Bug 4456

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.