Bug 441219

Uhm. This is filed against the wrong component.

And still is ... moving to compiz.

01:00.0 VGA compatible controller: ATI Technologies Inc M24 1P [Radeon Mobility
X600]


Default F9 Install showing the same thing.  (is the default wallpaper dynamic?)

(In reply to comment #3)
> 01:00.0 VGA compatible controller: ATI Technologies Inc M24 1P [Radeon Mobility
> X600]
> 
> 
> Default F9 Install showing the same thing.  (is the default wallpaper dynamic?)

Yes it is.

Can you or Carlos test this scratch build: 
http://koji.fedoraproject.org/koji/taskinfo?taskID=556243

But please make sure that gnome-settings-daemon is restarted (ex: reboot or kill
and restart it).

Created attachment 301610 [details]
Patch used (don't draw to root window when a cm is running)

patch applied. Tests in progress... ;-)

Same problem with this version of gnome-settings-daemon.

install gnome-settings-daemon-2.22.1-0.2008.03.26.6.fc9.i386
reboot
same problem

*** Bug 442121 has been marked as a duplicate of this bug. ***

Moving to X blocker.

can you see if this happens with latest intel driver in F9?

Dave: 
I'm using the latest intel driver in F9, and still have the same issue. 

Whats worse is that enabling desktop effects closed/crashed the
gtk-window-decorator. Everything was still wobbly, and screen still flickered
once every minute or so. 

I'll try to get a stacktrace and attach it in a moment. 

Here's the info I could grab. If anyone knows a better way to get a stacktrace,
let me know. 
gtk-window-decorator: Screen 0 on display ":0.0" already has a decoration
manager; try using the --replace option to replace the current decoration manager.
compiz (video) - Warn: No 8 bit GLX pixmap format, disabling YV12 image format
compiz (core) - Warn: No GLXFBConfig for depth 32
compiz (core) - Warn: No GLXFBConfig for depth 32
compiz (core) - Warn: No GLXFBConfig for depth 32

F9 up to date, same problem.

I'm still seeing this too (well, until I fall back to metacity because it's
pretty unusable with the flicker).  This is incredibly visible in a feature that
we talk about a lot.   

I'm seeing this with the latest Intel driver, (oh---but now that I look
closer it looks like I'm only seeing it with DRI2 enabled).

Also, for anybody debugging this, besides the automatic flicker that
doesn't require any user intervention, (except waiting for it to
happen), it looks like it's easy to force the bug to manifest itself
by changing the desktop background. Specifically, changing between two
image folders causing the single quick blink, while switching between
two static images causes a *lot* of flashing, (all windows disappear,
old image is painted, new image is painted, maybe a quick blink, then
windows reappear).

I don't know if that's one bug or two, but it's definitely not a
smooth experience.

-Carl

*** Bug 440982 has been marked as a duplicate of this bug. ***

I debugged this today.  Found the bug and an easy patch.  Attaching for testing.

Created attachment 304349 [details]
patch for gnome-desktop

The bug was pretty simple:

  - Nautilus calls eel to set background

  - Eel first sets its window's background, then calls gnome-desktop's
libgnomeui to set the root window's background too (such that when nautilus is
killed, the background on the root window is correct)

  - gnome-desktop's gnome_bg_set_pixmap_as_root() does this:

/* Set the root pixmap, and properties pointing to it. We
 * do this atomically with XGrabServer to make sure that
 * we won't leak the pixmap if somebody else it setting
 * it at the same time. (This assumes that they follow the
 * same conventions we do)

So it does:

  1) Grab the server
  2) Get pixmap id of current background.  If successfull, destroy it.
  3) Set new background
  4) Ungrab server

Now to destroy a resource without risking disconnecting from the server, one
needs to push/pop an error trap around the operation.  For error traps to
actually work, one needs to flush before popping the trap.

Net result is, that function does: "grab server; do some stuff; flush; do some
other stuff; ungrab server".  Grabbing the server means the compositing manager
is not run/scheduled.  The flush though also flushes previous requests to
change the background of the nautilus window.  So when we finally ungrab, it's
a mess for the compositor to catch up, and all the flicker happens.

Solution is simple: do the pixmap destroy part after ungrabbing the server. 
That's what the patch does.  Will submit upstream too.

Humm, that doesn't seem to do it.  It's nondeterministic at best.

Behdad, if the server grab locking out the compositor is the root cause of the
problem, can we just ditch the grab ? I mean, what other apps do we expect to
set the root pixmap nowadays, xearth ?!

Given normal blocker criteria, I don't see this as a blocker at this point.
Moving to target.

The patch in comment #19 seems to work just fine for me. Switching between different static backgrounds 
(as suggested in comment #16) is smooth and flawless, and there's no flicker with the slideshow 
background.

Behdad, are you *sure* this patch isn't right? 

The patch in comment #19 seems to work fine for me as well.

*** Bug 444380 has been marked as a duplicate of this bug. ***

I spent some time looking into the issue, and here's my understanding of
what is happening:

 * gnome-desktop/libgnome-desktop/gnome-bg.c:gnome_bg_set_pixmap_as_root()
   calls XClearWindow (display, RootWindow (display, screen_num));

 * That should have no effect since compiz and the metacity compositor
   use the "composite overlay window", a magic window that is on top
   of everything, and should obscure everything. 

 * However, for reasons that I don't completely understand, the composite
   overlay window is not clipping drawing on the root window; if I, for
   example, draw a rectangle on the root window using GDK, that appears
   directly on the screen. Debugging the X server, I can also see that
   the root window is unclipped.

   My best guess at this point is that the composite overlay window got
   caught in the XCompositeRedirectSubwindows() call, and that broke
   the clip processing.

I think Behdad's patch likely doesn't do anything at all, but in some
restarts the clipping may be fine, and in others not fine, so there is
a placebo effect.

Changing component based on my understanding of the location of the issue.

Debugged along with Keith Packard, he came up with a patch which should
be going into Xorg git soon. Upstream bug is:

https://bugs.freedesktop.org/show_bug.cgi?id=15823

Works for me with xorg-x11-server-*-1.4.99.901-28.20080415.fc9

Carlos, could you still reproduce this with the Xorg server from the above shown
package?

It seems to be ok for me too with xorg-x11-server-Xorg.x86_64
0:1.4.99.901-28.20080415 package.

Great job all, see you on may 13th... ;-)

Thank you

(In reply to comment #31)
> It seems to be ok for me too with xorg-x11-server-Xorg.x86_64
> 0:1.4.99.901-28.20080415 package.

Cool!

> Great job all, see you on may 13th... ;-)

Where?