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 657071 - Graphical artifacts when using GNOME
Graphical artifacts when using GNOME
Status: RESOLVED FIXED
Product: mutter
Classification: Core
Component: general
git master
Other Linux
: Normal major
: ---
Assigned To: mutter-maint
mutter-maint
: 658072 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2011-08-22 11:27 UTC by Patryk Zawadzki
Modified: 2014-07-08 02:17 UTC
See Also:
GNOME target: 3.2
GNOME version: ---


Attachments
snapshot of the texture corruption (181.23 KB, image/jpeg)
2011-09-13 16:46 UTC, Emmanuele Bassi (:ebassi)
  Details
Fix missed application redraws (2.04 KB, patch)
2011-09-14 18:19 UTC, Owen Taylor
committed Details | Review

Description Patryk Zawadzki 2011-08-22 11:27:48 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.
Comment 1 Rui Matos 2011-09-01 18:27:19 UTC
A workaround for now is using the following env var:

CLUTTER_PAINT=disable-clipped-redraws:disable-culling
Comment 2 Rui Matos 2011-09-01 18:29:48 UTC
> 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.
Comment 3 Patryk Zawadzki 2011-09-01 22:34:14 UTC
Indeed, it seems to work around the problem.
Comment 4 Emmanuele Bassi (:ebassi) 2011-09-02 07:37:00 UTC
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.
Comment 5 Rui Matos 2011-09-02 11:14:33 UTC
(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.
Comment 6 Rui Matos 2011-09-02 16:43:04 UTC
*** Bug 658072 has been marked as a duplicate of this bug. ***
Comment 7 Rui Matos 2011-09-02 16:44:23 UTC
By now I've seen reports of this bug under nouveau, radeon and intel.
Comment 8 Joe Barnett 2011-09-02 17:25:40 UTC
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.
Comment 9 Joe Barnett 2011-09-08 21:41:35 UTC
taking back my previous message, i think i just wasn't setting the env variable for the gnome-shell session correctly
Comment 10 Aurélien Naldi 2011-09-13 08:29:37 UTC
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.
Comment 11 Emmanuele Bassi (:ebassi) 2011-09-13 08:42:21 UTC
(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.
Comment 12 Emmanuele Bassi (:ebassi) 2011-09-13 08:44:29 UTC
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?
Comment 13 Guillaume Ayoub 2011-09-13 11:13:17 UTC
The bug has been reported here for Intel hardware:
https://bugs.freedesktop.org/show_bug.cgi?id=40623
Comment 14 Emmanuele Bassi (:ebassi) 2011-09-13 16:46:00 UTC
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.
Comment 15 Owen Taylor 2011-09-14 15:23:31 UTC
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.
Comment 16 Adam Williamson 2011-09-14 18:18:38 UTC
for completeness, there's also an active Fedora report for this:

https://bugzilla.redhat.com/show_bug.cgi?id=720605
Comment 17 Owen Taylor 2011-09-14 18:19:00 UTC
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.
Comment 18 drago01 2011-09-14 18:26:38 UTC
Review of attachment 196531 [details] [review]:

This makes sense. Maybe call the subject "Don't miss application redraws" but otherwise fine.
Comment 19 Adam Williamson 2011-09-14 19:11:43 UTC
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.
Comment 20 Adam Williamson 2011-09-14 19:12:46 UTC
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
Comment 21 Eric Appleman 2012-03-03 20:16:34 UTC
This isn't fixed in 3.2 or 3.4

Sandybridge GPU still tears unless CLUTTER_PAINT=disable-clipped-redraws:disable-culling is used
Comment 22 André Klapper 2012-03-04 20:47:11 UTC
Eric: Sandybridge has not been mentioned here before - might make sense to file a separate report with more info refering to this one.
Comment 23 Brendan Long 2014-07-07 22:43:48 UTC
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.
Comment 24 Brendan Long 2014-07-08 02:17:43 UTC
It looks like the vsync issue is here:

https://bugzilla.gnome.org/show_bug.cgi?id=711028