GNOME Bugzilla – Bug 657071
Graphical artifacts when using GNOME
Last modified: 2014-07-08 02:17:43 UTC
I am running stock GNOME 3.0 (distribution is PLD but it should not matter) with the following packages upgraded: mutter-3.1.4-1.x86_64 clutter-1.7.10-1.x86_64 cogl-1.7.6-1.x86_64 These three are enough to trigger graphical glitches. The result looks like if some parts of the screen were not properly marked as "dirty" before redrawing. For example switching tabs in tabbed programs can result in new tab being selected but old tab contents being visible or the other way around. It's especially annoying when working in gvim and letters that you type are not painted correctly. My graphical stack (card is an NV86, GeForce 8600M GS): Mesa-libEGL-7.12-0.20110819.1.x86_64 Mesa-libGLES-7.12-0.20110819.1.x86_64 Mesa-libGLU-7.12-0.20110819.1.x86_64 Mesa-libGL-7.12-0.20110819.1.x86_64 Mesa-utils-7.8.2-2.x86_64 Mesa-libOpenVG-7.12-0.20110819.1.x86_64 Mesa-dri-driver-nouveau-7.12-0.20110819.1.x86_64 Mesa-dri-driver-swrast-7.12-0.20110819.1.x86_64 The same happens with official Mesa 7.11. Upgrading gnome-shell to the latest 3.1.x does not help.
A workaround for now is using the following env var: CLUTTER_PAINT=disable-clipped-redraws:disable-culling
> CLUTTER_PAINT=disable-clipped-redraws:disable-culling Furthermore I found that running with this env var makes gnome-shell vsync properly while it doesn't without it.
Indeed, it seems to work around the problem.
so, both "disable-clipped-redraws" and "disable-culling" deal with the paint volume code paths, but the former also involves the GL and GLX implementations, whilst the latter is client-side code only. (In reply to comment #2) > > CLUTTER_PAINT=disable-clipped-redraws:disable-culling > > Furthermore I found that running with this env var makes gnome-shell vsync > properly while it doesn't without it. if disable-clipped-redraws makes everything sync to the vertical refresh rate then it is definitely a driver bug. this looks to me something similar to this nouveau bug: https://bugs.freedesktop.org/show_bug.cgi?id=35930 which has been marked as fixed a week ago.
(In reply to comment #4) > so, both "disable-clipped-redraws" and "disable-culling" deal with the paint > volume code paths, but the former also involves the GL and GLX implementations, > whilst the latter is client-side code only. Ok, but just for the record: using only one of those doesn't workaround the bug on this report (i.e. the redrawing not completing successfully). > (In reply to comment #2) > > > CLUTTER_PAINT=disable-clipped-redraws:disable-culling > > > > Furthermore I found that running with this env var makes gnome-shell vsync > > properly while it doesn't without it. > > if disable-clipped-redraws makes everything sync to the vertical refresh rate > then it is definitely a driver bug. > > this looks to me something similar to this nouveau bug: > > https://bugs.freedesktop.org/show_bug.cgi?id=35930 > > which has been marked as fixed a week ago. Yes, this is another bug which I shouldn't have mentioned here now that I think about it. Sorry for this noise.
*** Bug 658072 has been marked as a duplicate of this bug. ***
By now I've seen reports of this bug under nouveau, radeon and intel.
workaround env variable doesn't seem to work for me on radeon; do get fewer graphical artifacts, but still get completely unrepainted windows/tabs when switching tabs in chromium-browser/gnome-terminal, and overall feels jumpy/slower/stuttery.
taking back my previous message, i think i just wasn't setting the env variable for the gnome-shell session correctly
I have the same problem on two different computers with intel GPU. For me, running CLUTTER_PAINT=disable-clipped-redraws:disable-culling gnome-shell --replace seems to fix the problem: I can run "ps aux" 10 times in a gnome-terminal without getting partial screen update. Note that with "CLUTTER_PAINT=redraws", ps output works as well, the added frame probably force some extra redraw and indirectly solves it.
(In reply to comment #10) > Note that with "CLUTTER_PAINT=redraws", ps output works as well, the added > frame probably force some extra redraw and indirectly solves it. the "redraws" debug mode implicitly disables culling and clipped redraws.
let's try to speed this thing up. would it be possible for someone experiencing this issue to bisect either mutter or clutter — preferably the former, to rule out changes in the compositor code?
The bug has been reported here for Intel hardware: https://bugs.freedesktop.org/show_bug.cgi?id=40623
Created attachment 196421 [details] snapshot of the texture corruption since taking a screenshot will cause a revalidation of the damaged area, I had to take a snapshot with my mobile phone. you can see the corrupted area on the left hand side of the window, and at the top; the first tab is selected, but the highlight is on the second tab. this looks to me like a wrong clipped redraw caused by the wrong paint volume being reported.
After a lot of debugging, I finally have a theory. The key to this is that Mutter uses XDamageReportBoundingBox Say that we have an application window is damaged twice in quick succession - for simplicity - the entire window. X server Mutter ======== ====== Draws to the window flushes GLX buffers Sends mutter a damage event Receives damage event Draws to the window Does not flush GLX buffers - be because: Does not send mutter a damage event Calls XSubtractDamage() Paints window Flushes GLX buffers Flushes GLX buffers Note that the paint occurs after the XSubtractDamage that subtracts all the damage, so it's supposed to paint everything, but at the kernel level, the buffers are submitted so that the Mutter paint is _before_ the second X server paint.
for completeness, there's also an active Fedora report for this: https://bugzilla.redhat.com/show_bug.cgi?id=720605
Created attachment 196531 [details] [review] Fix missed application redraws Our usage of DamageReportBoundingBox was causing us to miss some updates when an area of the screen was drawn twice in rapid succession. Add an explicit XSync() call to force the server to flush rendering to the kernel before we draw.
Review of attachment 196531 [details] [review]: This makes sense. Maybe call the subject "Don't miss application redraws" but otherwise fine.
in case anyone else scratches their head, yes, there's a '+' missing in the version of the patch attached to this bug. The attached version doesn't apply and looks like it does nothing but add a big comment :) there should be a + in front of 'XSync (xdisplay, False);', obviously.
if you want to pull this patch somewhere, you may as well just grab it from upstream: http://git.gnome.org/browse/mutter/patch/?id=2dc5693c60a2952fdb703098c5e50d80eb976f86
This isn't fixed in 3.2 or 3.4 Sandybridge GPU still tears unless CLUTTER_PAINT=disable-clipped-redraws:disable-culling is used
Eric: Sandybridge has not been mentioned here before - might make sense to file a separate report with more info refering to this one.
Is there a bug report for this on later video cards? I'm using Haswell graphics (i7-4770) and have the same vsync issue (particularly annoying when watching fast-moving videos like anime). The workaround still works though. I can open a new bug if one doesn't exist.
It looks like the vsync issue is here: https://bugzilla.gnome.org/show_bug.cgi?id=711028