After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 314617 - Background in nautilus window not redrawn properly.
Background in nautilus window not redrawn properly.
Product: nautilus
Classification: Core
Component: [obsolete] Backgrounds Emblems and Themes
Other Linux
: Normal normal
: ---
Assigned To: Nautilus Maintainers
Nautilus Maintainers
Depends on: 314616
Reported: 2005-08-26 21:02 UTC by Pat Suwalski
Modified: 2006-02-07 16:22 UTC
See Also:
GNOME target: ---
GNOME version: 2.11/2.12

Screenshot of issue. (81.87 KB, image/png)
2005-08-26 21:03 UTC, Pat Suwalski
Working screenshot of the problem. (15.14 KB, image/png)
2005-09-05 15:57 UTC, Pat Suwalski
Sample GTK+ Program (1023 bytes, text/plain)
2005-09-06 08:45 UTC, Christian Neumair

Description Pat Suwalski 2005-08-26 21:02:43 UTC
Version details: from garnome-2.11.x
Distribution/Version: Gentoo

I have a background set in my nautilus windows via the gconf key
"/apps/nautilus/preferences/background_filename", from back in the 2.0/2.2 days
when a global background was UI-accessible. The key is set to

The image doesn't show when a window is first opened, and can be revealed by
redraw after selection or scrolling.

Per-folder backgrounds work ok.
Comment 1 Pat Suwalski 2005-08-26 21:03:26 UTC
Created attachment 51390 [details]
Screenshot of issue.
Comment 2 Pat Suwalski 2005-08-26 21:05:13 UTC
On further inspection of the screenshot, the background didn't capture at all,
since it disappears when the window loses focus.
Comment 3 Christian Neumair 2005-09-03 15:34:42 UTC
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,
        } else {
                color = nautilus_file_get_metadata (file,
                image = nautilus_file_get_metadata (file,
                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) {
                                (&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.

Comment 4 Christian Neumair 2005-09-03 21:54:38 UTC
Setting to NEEDINFO.
Comment 5 Pat Suwalski 2005-09-05 15:57:57 UTC
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

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 server. It works properly.

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

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.
Comment 6 Christian Neumair 2005-09-05 16:11:56 UTC
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 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
servers. Do you use the OSS or the vendor-provided flavor of the radeon driver?
Comment 7 Pat Suwalski 2005-09-05 17:47:10 UTC
pixbuf-demo works just fine, no funny graphical problems.

I am using the 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 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.
Comment 8 Christian Neumair 2005-09-05 18:13:38 UTC
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.
Comment 9 Christian Neumair 2005-09-05 18:37:54 UTC
btw. what version are you on? I have a radeon video card as well and may
be able to reproduce this issues.
Comment 10 Pat Suwalski 2005-09-05 21:18:17 UTC
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

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 7.0.0 RC0.
Comment 11 Christian Neumair 2005-09-06 08:45:36 UTC
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`
Comment 12 Pat Suwalski 2005-09-06 19:34:05 UTC
This works properly on both of the machines I tested on.
Comment 13 Pat Suwalski 2005-10-15 01:40:00 UTC
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.
Comment 14 Pat Suwalski 2006-02-07 16:22:18 UTC
This is actually a cairo bug related to the references XCopyArea bug on radeon.