i have this problems too ... but only on the primary monitor, secondary monitor has no corruptions.

using gnome 3.10 from arch testing.

OpenGL vendor string: X.Org
OpenGL renderer string: Gallium 0.4 on AMD RV770
OpenGL core profile version string: 3.1 (Core Profile) Mesa 9.3.0-devel (git-848c0e7)
OpenGL core profile shading language version string: 1.40

In my case:

OpenGL vendor string: Intel Open Source Technology Center
OpenGL renderer string: Mesa DRI Intel(R) Sandybridge Desktop x86/MMX/SSE2
OpenGL core profile version string: 3.1 (Core Profile) Mesa 9.2.0
OpenGL core profile shading language version string: 1.40

with xf86-video-intel-2.21.15 xorg driver (uxa acceleration) and the i915 kernel driver from the 3.11.1 linux kernel.

I am experiencing the same issue with 3.10.0.1 from Archlinux stable.

I have recorded the phenomenon to video:
http://www.sendspace.com/file/w112xo

Restarting the shell seems to alleviate this, at least temporarily. Logging out and back in will retrigger the bug. (Something about the transition animation, perhaps?)

OpenGL vendor string: NVIDIA Corporation
OpenGL renderer string: GeForce GTX 660/PCIe/SSE2
OpenGL core profile version string: 4.3.0 NVIDIA 325.15
OpenGL core profile shading language version string: 4.30 NVIDIA via Cg compiler

Same issue here with Nvidia drivers on Arch, kernel 3.11.4. Looks identical to the video posted by the previous commenter.

When multiple displays are connected, this only happens on primary display, not on secondary or tertiary.

The artifact does *not* appear in Activities Overview mode.


OpenGL vendor string: NVIDIA Corporation
OpenGL renderer string: GeForce GT 640/PCIe/SSE2
OpenGL core profile version string: 4.3.0 NVIDIA 325.15
OpenGL version string: 4.3.0 NVIDIA 325.15

so, we all have different video cards .. maybe an arch linux specific problem?

Same here, i am on Arch using intel driver.

Intel driver xf86-video-intel 2.21.15.
Kernel: 3.11.4

I confirm that there is no bug in the Activities Overview, nor on a secondary screen.

By the way, removing the autologin with GDM solved this problem.

(In reply to comment #6)
> By the way, removing the autologin with GDM solved this problem.

I cannot corroborate this on my part; I do not have autologin active.

The error only appears on my desktop with the Nvidia card, my laptop also has Arch Linux, same packages, and does not display the error

OpenGL vendor string: Intel Open Source Technology Center
OpenGL renderer string: Mesa DRI Intel(R) Sandybridge Mobile 
OpenGL core profile version string: 3.1 (Core Profile) Mesa 9.2.1
OpenGL version string: 3.0 Mesa 9.2.1

Same problem here. Arch, Nvidia.

Changing the display configuration in the control center (setting another display to primary and back again) seems to be a workaround. The problem manifests again after a shell restart.

Actually, Alt+F2, type "r" and pres enter will resolve it until next login.

@Marko not on my system

restarting the shell with Alt-F2 r works for me.

The wallpaper isn't redrawn. That's all. Restarting the shell after boot always resolves the issue for me.

When testing Fedora 20 alpha I didn't encountered this problem.

Arch Linux up-to-date with Intel HD 3000

Same issue for me. Nvidia drivers, Archlinux. Also, noticed that if I hit the top left corner to display windows, I can still see the desktop, but it stops drawing again once returning to a standard window's focus.

on my system xrandr --noprimary fixes the problem until the next reboot

If 'Switch User', the mouse cursor dissapears on gdm, and on login the symbol for volume on the top-right panels isn't drawn.

intel HD 3000 and arch linux.

Another confirmation. New install of Arch, Gnome 3.10 and Nvidia drivers. Artifacts are on primary display, secondary is functioning properly.

Another confirmation.

$ lspci -k | grep -A 2 -i "VGA"
01:00.0 VGA compatible controller: NVIDIA Corporation GK107 [GeForce GTX 650] (rev a1)
    Subsystem: ZOTAC International (MCO) Ltd. Device 2263
    Kernel driver in use: nvidia

$ pacman -Ss nvidia | grep -i 'install'
extra/libcl 1.1-3 [Installiert]
extra/libvdpau 0.7-1 [Installiert]
extra/nvidia 325.15-9 [Installiert]
extra/nvidia-libgl 325.15-1 [Installiert]
extra/nvidia-utils 325.15-1 [Installiert]
multilib/lib32-nvidia-libgl 325.15-1 [Installiert]
multilib/lib32-nvidia-utils 325.15-1 [Installiert]

Arch thread: https://bbs.archlinux.org/viewtopic.php?pid=1334330#p1334330

I have a similiar issue. I reported the bug (duplicate) at https://bugzilla.gnome.org/show_bug.cgi?id=709689 Yet, I just want to post the movie of this effect here for confirmation:

https://buhman.org/gnome-709689-t.ask-20131008.avi

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

It's not an issue with your graphics card; it's a race condition where the wallpaper fails to load sometimes.

The reason you're seeing the window trails and strange artifacts is because we don't clear the draw buffer, meaning that it has "undefined contents". On most graphics drivers, it will just reuse an old buffer that it drew to before.

(In reply to comment #22)
> It's not an issue with your graphics card; it's a race condition where the
> wallpaper fails to load sometimes.
> 
> The reason you're seeing the window trails and strange artifacts is because we
> don't clear the draw buffer, meaning that it has "undefined contents". On most
> graphics drivers, it will just reuse an old buffer that it drew to before.

So clearing the draw buffer should resolve the issue?

It will prevent the rendering issues, but the background will be gray, not your wallpaper. We're looking into why the background isn't loading, but if you just want to prevent the headache-inducing flicker for now, hit Alt-F2, type "lg", then type "global.stage.no_clear_hint = false;" into the prompt that comes up, then hit Escape.

(In reply to comment #24)
> ... type "lg", then type "global.stage.no_clear_hint = false;" into the prompt 
> that comes up, then hit Escape.
This works well. With dual head setup just switch primary and secondary display
without confirmation. This works, too.

(In reply to comment #24)
> It will prevent the rendering issues, but the background will be gray, not your
> wallpaper. We're looking into why the background isn't loading, but if you just
> want to prevent the headache-inducing flicker for now, hit Alt-F2, type "lg",
> then type "global.stage.no_clear_hint = false;" into the prompt that comes up,
> then hit Escape.

OK, thanks for the feedback! Your workaround works as described.

Can you confirm that this is a bug in gnome 3.10 which must be fixed?

Yes, this is our bug. I'm looking into fixing it.

That's strange .. the background has to be loaded somehow because if you go to overview it gets drawn. Also secondary outputs are ok (same background). The shell somehow forgets the background for the primary display only?

Just a side note: this is not arch specific; it's observed on openSUSE 13.1beta/rc as well.

I think you're observing a DRI2 bug that I reported last month : https://bugs.freedesktop.org/show_bug.cgi?id=69438

My recording of the issue seems pretty similar to what you have : https://www.youtube.com/watch?v=pOwxRp2Z310

Basically buffer swaps get out of sync and you're seeing the back buffer.
Chris Wilson pointed to a patch that is sadly not upstream yet : http://cgit.freedesktop.org/~ickle/xserver/commit/?h=dri2-invalidate&id=eb256400317b98e999b5dabe06a82970bd922068

Would someone care to recompile its Xserver? :)

Got xorg-server package sources from Arch Build System, applied patch, compiled, installed the generated xorg-server and xorg-server-common packages.

After a reboot, the issue is still here.

Arch Linux up-to-date with Intel HD 3000

(In reply to comment #30)
> I think you're observing a DRI2 bug that I reported last month :
> https://bugs.freedesktop.org/show_bug.cgi?id=69438
> 
> My recording of the issue seems pretty similar to what you have :
> https://www.youtube.com/watch?v=pOwxRp2Z310
> 
> Basically buffer swaps get out of sync and you're seeing the back buffer.

I don't think this is the issue, since if you set the no_clear_hint, it works fine. What's happening is that we never clear the backbuffer, and do our drawing clipped with the scissor rect, so we just paint on top of the old backbuffer contents.

I recently filed https://bugzilla.gnome.org/show_bug.cgi?id=710082 , which is also a redraw-related bug. No idea if there could be a connection, though. 710082 affects both of my machines, while 709313 affects only one.

Issue solved on Arch Linux, it had something to do with package management.

# pacman -S gnome
# pacman -S gtk3
# pacman -S libtxc_dxtn
# reboot

Found here: https://bbs.archlinux.org/viewtopic.php?pid=1338541#p1338541

@Clément thanks. That resolved it for me.

I had not installed all the packages from the gnome group, and just reinstalling what I already had did not solve the problem for me. So I investigated further and found out that just installing the previously not installed gnome-shell-extensions package fixed it for me.

However, looking at the list of files installed by this package I fail to see the real reason for this behavior. But I can reproduce this reliable by installing or uninstalling the package and logging of and on again. Without the package my external desktop does not draw properly, with the package everything is fine.

As arch just uses the upstream package here I don't see a specific Arch packaging problem in this case, but feel free to correct me.

@Philipp, thanks that fixes the problem for me too.

?? That would only imply that any of the gnome-shell-extensions does more than 'just be there';

I'd not consider this conclusively fixed (only worked around)

@Philipp, awesome. Let's investigate further!

In the meantime, I'll file a bug to Arch Linux to make gnome-shell depend on gnome-shell-extensions, that will fix it!

Bug report on Arch Linux with proposed solution :

https://bugs.archlinux.org/task/37412

Comment #40: This is absolutely not a fix.  It doesn't work for me on my distribution, but even if it did all that is happening is that it is altering the timing of a race condition.  Just wait for a proper fix.  Since this bug makes gnome-3.10 unusable for a large proportion of gnome users, I assume someone somewhere is working on it.

(In reply to comment #41)

Yes, this is just a temporary workaround. What distro are you using?

Unrelated, but you say you are using UXA. If I remember it correctly it's not the recommended way anymore as SNA is way faster and doesn't causes any problems. In fact I think UXA is causing problems with gnome-shell.

(In reply to comment #42)
> Yes, this is just a temporary workaround. What distro are you using?
> 
> Unrelated, but you say you are using UXA. If I remember it correctly it's not
> the recommended way anymore as SNA is way faster and doesn't causes any
> problems. In fact I think UXA is causing problems with gnome-shell.

SNA is not stable. We had to disable it in Fedora after it kept giving us rendering issues.

This issue is independent from UXA/SNA. I use UXA due to [1], but I tried SNA to see if it fixes this issue, which it didn't.

[1] https://bugs.freedesktop.org/show_bug.cgi?id=68410

Oh, I wasn't aware of that. I kept using SNA since GNOME 3.8 because gnome-shell wouldn't start with UXA activated. Never got any rendering issues with it, and now it's activated by default on Arch Linux.

Oh. My. God. I just enabled UXA and the shell has never been so smooth on my laptop. I was complaining about performance issues since 3.8 and that was the cause. Never been so wrong!

Installing the package gnome-shell-extensions on my system (Arch) fixed it as well. I tracked it down further and noticed that the error is caused when the directory /usr/share/gnome/shell/modes does not exist.

This is probably a bug in gnome-shell/js/misc/fileUtils.js when _collectFromDirectoryAsync is called with a non-existing directory.

A workaround is to just create the directory /usr/share/gnome-shell/modes

Couldn't find anything wrong with fileUtils.js, maybe it's some kind of race condition after all.

Created attachment 257787 [details] [review]
workaround patch for bug

I've re/installed the Arch Gnome package:

pacman -S gnome

some packages were missing:

...
installing gnome-shell-extensions
installing grilo
installing grilo-plugins
installing gucharmap
installing totem-plugin
...

Everything else was reinstalled. Maybe one of these packages was the cause. It's now working fine with dual head displays, too. Therefore, I guess, it's related to the Arch "gnome-shell-extensions" as someone mentioned before.

(In reply to comment #47)
> A workaround is to just create the directory /usr/share/gnome-shell/modes

For reference: this is in fact what we do currently on openSUSE 13.1 and the issue disappeared as well.. interesting to see that the pure presence of the directory changes it all...

(In reply to comment #47)
> Installing the package gnome-shell-extensions on my system (Arch) fixed it as
> well. I tracked it down further and noticed that the error is caused when the
> directory /usr/share/gnome/shell/modes does not exist.
> 
> This is probably a bug in gnome-shell/js/misc/fileUtils.js when
> _collectFromDirectoryAsync is called with a non-existing directory.
> 
> A workaround is to just create the directory /usr/share/gnome-shell/modes

Otto,

thanks for troubleshooting this. Interestingly, creating the "modes" directory solved the issue for me but I also have gnome 3.10 installations which do not show the same "background loading error" and also do not have the "modes" directory available.

I tried to figure how the list of directories passed to _collectFromDirectoryAsync is built, looks like it is gathered by glib.get_system_data_dir but then I'm not sure how does glib gets those.

On my laptop, I also found that using UXA in favor of SNA fixes the issue...

Created attachment 259229 [details] [review]
layout: Fix several issues with the background management code

If monitor-changed fires at startup, it will destroy all of the
backgrounds, but since this._isStartup is true, won't recreate any
of them. Additionally, since _bgManagers is indexed by monitor index,
if the primary index is not 0, it could become a sparse array (e.g.
[undefined, undefined, primaryBackground]), and our for loop will
crash trying to access properties of undefined.

Fix both of these issues by always creating background managers for
every monitor, hiding them on startup but only showing them after
the startup animation is complete.

One thing we need to watch out for is that while LayoutManager is
constructing, Main.uiGroup / Main.layoutManager will be undefined,
so addBackgroundMenu will fail. Fix this by passing down the uiGroup
to the background menu code.

Could somebody test this patch on a git master version of gnome-shell? I managed to track down this issue and found it to be this bug, but it really should only happen for people with multimonitor layouts.

Are people seeing this bug on single-monitor layouts, with git master and this patch applied?

Review of attachment 259229 [details] [review]:

Thanks for taking this on!

::: js/ui/layout.js
@@ +354,3 @@
 
+    _addBackgroundMenu: function(bgManager) {
+        BackgroundMenu.addBackgroundMenu(bgManager.background.actor, this.uiGroup);

might make sense to pass in the layoutManager here instead of the uiGroup, in the same way we pass it into the BackgroundManager (just for consistency).  Doesn't really matter, though.

@@ +359,1 @@
     _createBackground: function(monitorIndex) {

should probably be called _createBackgroundManager now (though, again, doesn't really matter)

@@ -396,3 @@
             return;
 
-        if (this._startingUp)

it's a shame we can't get rid of this flag entirely, but I guess we're using it now for queueUpdateRegions

@@ +393,3 @@
 
+        for (let i = 0; i < this.monitors.length; i++)
+            this._bgManagers.push(this._createBackground(i));

Though since we have the flag, it might make sense to set visiblity based on it, here, so if there is a monitor hotplug before the start up animation finishes, the new monitors don't light up with the background in place prematurely, before the other monitors.

@@ +592,3 @@
+            for (let i = 0; i < this.monitors.length; i++) {
+                if (i != this.primaryIndex)
+                    this._bgManagers[i].background.actor.hide();

so we wouldn't have the hide here, if we set visiblity from startingUp above in updateBackgrounds, which also would save us one run through the loop at startup.

Attachment 259229 [details] pushed as 831bd07 - layout: Fix several issues with the background management code


Pushed with suggested fixes.

work perfectly for me on multi-monitors configuration.

Would be great to see this patch in G3.10.x gnome-shell releses as well.

It's been reported in the Fedora forums:

http://forums.fedoraforum.org/showthread.php?t=295844

so yeah, I think people would appreciate a 3.10 backport if possible!