Created attachment 51390 [details]
Screenshot of issue.

On further inspection of the screenshot, the background didn't capture at all,
since it disappears when the window loses focus.

Thanks for your bug report!
I cannot reproduce this issue. If you have access to the Nautilus source code
and some time to compile it on your own, I would like you to add

g_warning ("got image, color %s, %s for URI %s",
           color, image, nautilus_file_get_uri (file));

code to libnautilus-private/nautilus-directory.c after the following code block:

        if (eel_background_is_desktop (background)) {
                nautilus_file_background_read_desktop_settings (&color, &image,
&placement);
        } else {
                color = nautilus_file_get_metadata (file,
                                                   
NAUTILUS_METADATA_KEY_LOCATION_BACKGROUND_COLOR,
                                                    NULL);
                image = nautilus_file_get_metadata (file,
                                                   
NAUTILUS_METADATA_KEY_LOCATION_BACKGROUND_IMAGE,
                                                    NULL);
                placement = EEL_BACKGROUND_TILED; /* non-tiled only avail for
desktop, at least for now */

                /* if there's none, read the default from the theme */
                if (color == NULL && image == NULL) {
                        nautilus_file_background_get_default_settings
                                (&color, &image, &placement);
                }
        }

Maybe you could then run Nautilus in a terminal (instructions under [1]) and
send us the output for the relevant folders?

Sorry for the inconvinience, but without further input we're unable to track
this issue down.

[1] http://live.gnome.org/Nautilus#CommonProblems

Setting to NEEDINFO.

Created attachment 51832 [details]
Working screenshot of the problem.

Thanks for the extensive response. I put in the debugging statement and I get
debug information completely as expected:

** (nautilus:8471): WARNING **: got image, color ,
file:///usr/share/nautilus/patterns/snow_ridge.png for URI
file:///home/pat/Fandom

So it's not a matter of it not loading the image or anything like that.

In the working screenshot you can see the two icons I have mouseover'd have
gotten a background, as has the area to the left and the right where Gimp's
windows overlapped and were redrawn when the screenshot was taken.

I tried Luis' LiveCD with the same Gnome versions, but that has a
not-bleeding-edge X.org server. It works properly.

As such, I have a feeling I'm chasing more ghosts like in this bug of mine:

    http://bugzilla.gnome.org/show_bug.cgi?id=314616

All the same, based on my hardware, it's not clear whether this is
cairo-affected-radeon-only or if this is across the board for video cards and
the bleeding-edge X servers.

Thanks for taking the time!
Do you only see such awkward behavior in Nautilus or in other apps as well? For
instance, does the gtk-demo pixbuf demo work correctly? I fear this is really an
X.org issue - maybe we do very uncommon things, but this kind of basic image
compositing/drawing normally shouldn't be too hard for X. I've also read
somewhere that the radeon binary driver is still very buggy with recent X.org
servers. Do you use the OSS or the vendor-provided flavor of the radeon driver?

pixbuf-demo works just fine, no funny graphical problems.

I am using the X.org radeon driver. As noted in the other report, it's not just
my chip, there are definitely problems with recent X.orgs and gnome/cairo.

I am attempting to raise this issue a little stronger with the X.org guys, as
this really breaks the desktop experience.

Anyway, it seems that while the other bug is about redraws too often, this bug
is about a lack of redraws. And the fact that it works when I use the same
version of nautilus and gnome from the liveCD and only the X version is
different points the finger at X.

I do not know how to proceed from here. It does not seem to be a Nautilus bug,
though only Nautilus seems affected by both this and my other bug.

OK, another idea: in nautilus_connect_background_to_file_metadata, add:

g_signal_connect (widget, "expose-event",
                  G_CALLBACK (widget_expose_cb), background);

the referenced function should look like

static void
widget_expose_cb (GtkWidget *widget,
                  GdkEventExpose *event,
                  EelBackground *bg)
{
  char *uri;
  uri = eel_background_get_image_uri (bg);
  g_warning ("got expose event with background %s", uri);
  g_free (uri);
}

By testing whether the terminal gives you any output when the new bg image URI
is set, we can find out whether a redraw was queued.

btw. what X.org version are you on? I have a radeon video card as well and may
be able to reproduce this issues.

This patch shows it "works" as well. Whenever I expose a window with Alt-Tab I get:

** (nautilus:1239): WARNING **: got expose event with background
file:///usr/share/nautilus/patterns/snow_ridge.png

The window remains a light-grey, however. Also, there are no longer any icons,
but I would say that is because the expose event has been replaced.

The server is X.org 7.0.0 RC0.

Created attachment 51855 [details]
Sample GTK+ Program

OK, thanks for your additional feedback. We'll now find out whether the issue
is within GTK+ or has something to do with eel. Please tell us whether the
attached sample program works for you. It should display the ribbed background
correctly. Please compile it with:
gcc -o bgtest bgtest.c `pkg-config --libs --cflags gtk+-2.0`

This works properly on both of the machines I tested on.

The problem has gone away within the last week since the Gnome Summit. In that
time, I've gotten a new xorg-xserver from 20051013. I have to assume that it
fixed it.

This is actually a cairo bug related to the references XCopyArea bug on radeon.