Created attachment 50890 [details] Emacs with parts of the screen not redrawn With some applications (emacs, gnome-terminal, epiphany), some parts of the screen are not refreshed, for example when some content is scrolled. This bug looks really, really similar to #32734 (fixed), as it happens for me with the same applications and has the same effects. I'm using mesa-7.11, intel-2.16.0 with sna, xorg-server-1.11, linux-3.1-rc4.
Have you tried testing with my composite fixes from http://cgit.freedesktop.org/~ickle/xserver/log/ ? That would be one useful extra datapoint. After that, if you can narrow down the amount of activity required to reproduce and then run with --enable-debug=full, there's a good chance that the cause will be reported except it will be a case of searching for a needle in a haystack.
My gnome-shell installation on my netbook is currently fried (thanks polkit and debian!). Checking the usual suspects under KDE and xfce4 compositing, I'm not seeing anything unusual (and damage related artifacts are usually quite easy to provoke).
(In reply to comment #1) > Have you tried testing with my composite fixes from > http://cgit.freedesktop.org/~ickle/xserver/log/ ? That would be one useful > extra datapoint. After that, if you can narrow down the amount of activity > required to reproduce and then run with --enable-debug=full, there's a good > chance that the cause will be reported except it will be a case of searching > for a needle in a haystack. Thanks, I'll try your fixes tomorrow. I'll try to find a way to reproduce this bug, but it really seems to be random. For example, when I scroll up and down a buffer in emacs, two or three different artifacts happen alternatively. (In reply to comment #2) > My gnome-shell installation on my netbook is currently fried (thanks polkit and > debian!). Checking the usual suspects under KDE and xfce4 compositing, I'm not > seeing anything unusual (and damage related artifacts are usually quite easy to > provoke). For me, the artifacts only happen with epiphany, emacs and gnome-terminal, when I use gnome-shell (not metacity). The bug is not happening often with gnome-terminal and epiphany, but is happening really often with emacs (with gtk3 support) . As I said in the description, that was exactly the same with the bug 32734.
I've tried your branch, but it doesn't solve the problem. Opening emacs in gnome-shell, and scrolling a buffer in emacs is an easy way to reproduce the bug for me. When the lines in the open buffer have different lengths, the bug is happening more often: the characters at the end of the long lines are drawn at the end of the short lines, when the short line is drawn at the position of the long line after a scroll. Another easier way: selecting lines with the mouse. If I move the mouse cursor slowly, everything is OK. If I move it quickly, some lines are not redrawn. Using gnome-shell's alt-tab to change the active window redraws the window correctly. I can reproduce this bug each time I move the cursor fast enough (and that's not so fast, really easy to reproduce). Here is a screenshot. The yellow rectangle is the cursor. The same bug happens in gnome-terminal: when I keep the enter key down, a cursor is drawn on some lines. Thank you for the tips, I'll try --enable-debug=full ASAP.
Created attachment 50917 [details] gnome-terminal with cursor artifact
Created attachment 50920 [details] Emacs with cursor artifact The text was selected in about 150 ms. If I select the text in about 1 s, the text is correctly highlighted.
The bug has been reported here for Gnome: https://bugzilla.gnome.org/show_bug.cgi?id=657071 That's definitely my bug. This bug report is really interesting, as it suggests that setting "CLUTTER_PAINT=disable-clipped-redraws:disable-culling" before launching gnome-shell resolves the problem (it works for me). I don't fully understand what it means, but I can imagine that it helps. And, as suggested, setting the environment variable also fixes gnome-shell's vsync.
Discussing this with Owen Taylor, it is not the driver at fault for a change. There is some debate as to where the problem truly lies, but the temporary solution seems to be for mutter to perform a timely round-trip to X in order to synchronize its drawing.
(In reply to comment #8) > Discussing this with Owen Taylor, it is not the driver at fault for a change. > There is some debate as to where the problem truly lies, but the temporary > solution seems to be for mutter to perform a timely round-trip to X in order to > synchronize its drawing. Thanks a lot.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.