Created attachment 117530 [details]
Chrome GPU information

This is the output of Chrome's chrome://gpu page, for reference.

I also reported the issue at the chromium bug tracker, at:

https://code.google.com/p/chromium/issues/detail?id=516679

Your Xorg.0.log is vital here. As would also confirming this with xf86-video-intel.git.

Created attachment 117536 [details]
X Log with UXA

Created attachment 117537 [details]
X Log with SNA

I added the Xorg log files, one for SNA and one for UXA. They do not report any issues, though.

I'll see if I can check with current git, but things are a bit problematic right now, as Debian is undergoing the libstdc++ transition and I might thus not be able to build things, because my chroot might not be able to install needed build dependencies.

I can reproduce it on current git.

Looks like a bog standard gnome-shell setup, right? I hope debian closely matches fedora...

One more useful task would be to run with --enable-debug=pixmap (and confirm that Xorg.0.log reports the extra assertions) and see if any fire.

--enable-debug=pixmap did not show anything new in the Xorg log.

You should see confirmation in the ./configure summary, and then in the log:

"SNA compiled with assertions enabled"
"SNA compiled with extra pixmap/damage validation"

Yeah, it's showing 

[168524.947] (II) intel(0): SNA compiled with extra pixmap/damage validation

but there's no error messages or anything else new coming after the initial set-up.

So, this does not seem to be caught by those assertions.

And yes, it should be relatively standard GNOME Shell 3.16.

For further reference, here are the versions of reverse dependencies of the intel driver.

ii  libc6                                  2.19-19
ii  libdrm-intel1                          2.4.62-1
ii  libdrm2                                2.4.62-1
ii  libpciaccess0                          0.13.4-1
ii  libpixman-1-0                          0.32.6-3
ii  libudev1                               224-1
ii  libx11-6                               2:1.6.3-1
ii  libx11-xcb1                            2:1.6.3-1
ii  libxcb-dri2-0                          1.10-3+b1
ii  libxcb-dri3-0                          1.10-3+b1
ii  libxcb-sync1                           1.10-3+b1
ii  libxcb-util0                           0.3.8-3
ii  libxcb1                                1.10-3+b1
ii  libxcursor1                            1:1.1.14-1+b1
ii  libxdamage1                            1:1.1.4-2+b1
ii  libxext6                               2:1.3.3-1
ii  libxfixes3                             1:5.0.1-2+b2
ii  libxinerama1                           2:1.1.3-1+b1
ii  libxrandr2                             2:1.5.0-1
ii  libxrender1                            1:0.9.8-1+b1
ii  libxshmfence1                          1.2-1
ii  libxtst6                               2:1.2.2-1+b1
ii  libxv1                                 2:1.0.10-1+b1
ii  libxvmc1                               2:1.0.9-1
ii  xserver-xorg-core [xorg-video-abi-19]  2:1.17.2-1

Having the same problem with Kwin 4.11.19 on gentoo

I've tried on several different computers to reproduce this, and have not. Considering that the bug will be the damage tracking going awry it is going to involve WM + timing. Do you have steps that can reliably reproduce it?

It seems to involve some sort of race, so it's not reliably debuggable. It sometimes took me up two 5 minutes of switching between tabs (just two tabs next to each other) by keyboard to reproduce this (clicking on the tabs does not seem to cause it).

I might check in Fedora 22 soon, I'm currently downloading a live image.

I did not have much time to check in Fedora, but on a first glance, there are no problems at all. Neither this, nor another Chrome rendering bug I experience on Debian (that one is not UXA/SNA related though):

https://code.google.com/p/chromium/issues/detail?id=516756

I also could not reproduce it under metacity, but that was only a very quick dry, so it might simply not have occured yet.

I could reproduce the window resizing bug I mentioned in the previous comment under metacity with compositing enabled, though.

So it seems like this may be a special combination of dependencies in Debian causing the issue (versions and/or patches).

I'm hitting it on Archlinux on gnome-shell (3.16) and kde (plasma 5), on Ivy Bridge and Broadwell hardware, in single and multi-monitor configurations. This bug has been here for a while, two month or so, but with recent chromium releases it became even worse. Chris, what chromium version are you running?

I am having the same issue. This system is debian sid, with kde plasma 5, so it appears it is not a problem with metacity.

I was seeing this problem with Gnome 3.16 and Chrome using Intel Drivers and my conclusion is this is somehow indeed related to Window manager.

As a workaround, try selecting "Use System title bar and Border" in chrome settings and see if this problem goes away. For me that fixed the problem.

I am seeing this on Arch Linux (x64) as well. I update my systems daily and starting seeing this bug somewhere between 13th to 23rd July on both my Broadwell laptop and Ivy Bridge PC. Looking at my update log, I believe it could be any of the following:

[2015-07-13 00:09] [ALPM] upgraded mesa (10.6.1-1 -> 10.6.2-1)
[2015-07-16 08:22] [ALPM] upgraded chromium (43.0.2357.132-1 -> 43.0.2357.134-1)
[2015-07-16 08:22] [ALPM] upgraded xorg-server (1.17.2-2 -> 1.17.2-3)
[2015-07-18 10:05] [ALPM] upgraded xorg-server (1.17.2-3 -> 1.17.2-4)
[2015-07-22 21:35] [ALPM] upgraded xf86-video-intel (1:2.99.917+364+gb24e758-1 -> 1:2.99.917+381+g5772556-1)
[2015-07-23 08:31] [ALPM] upgraded chromium (43.0.2357.134-1 -> 44.0.2403.89-1)

I don't like using UXA because I lose smooth gnome-shell overview animation so with SNA I am seeing this bug many times per day.

Created attachment 117632 [details]
Xorg.log.gz

Here's Xorg log with --enable-debug=full. Repaint failure happened around 16:59:30-17:00:53

(In reply to Hemant Kumar from comment #19)
> I was seeing this problem with Gnome 3.16 and Chrome using Intel Drivers and
> my conclusion is this is somehow indeed related to Window manager.
> 
> As a workaround, try selecting "Use System title bar and Border" in chrome
> settings and see if this problem goes away. For me that fixed the problem.

While using "System title bar and Border" fixes redrawing problem, it causes another weird problem which is - whenever I exit a full screen video, Chrome hangs completely (although not always). I will try to grab some logs of when this happens and post it here.

https://www.dropbox.com/s/t54yai92gq86621/Xorg.0.log.bz2?dl=0

Issue happened around 27758 +- 5 secs

To reproduce this issue I opened/switch/closed chromium tabs. Issue happened during a tab switch, chromium indicated it switched to new tab by highlighting tab header, but content of old tab still remained on the screen. After some time (1-1.5s) redraw happened.

I've noticed that it's enough to switch workspaces or enter gnome-shell overview mode to force chromium redraw.

For gnome it's possible to workaround the issue by adding "CLUTTER_PAINT=disable-clipped-redraws:disable-culling" to your environment variables (for archlinux it's /etc/environment)

@Vasily re comment #25, that definitely stops the problem, unlike the use "system title bar and borders" option which makes no difference. What disadvantage/compromise does this CLUTTER_PAINT workaround impose? I've not noticed anything.

@Mark B, as far as I understand it disables partial repaints, so it may result in worse performance and/or higher power consumption.

I can confirm the bug on latest Debian testing/stretch on Core M

Chromium 45.0.2454.85-1 (45.0.2454.85-1)
xserver-xorg 1.17.2 (xserver-xorg-core 2:1.17.2-1.1)
mesa 10.6.3 (10.6.3-1)
xserver-xorg-video-intel 2.99.917 (2:2.99.917-2)

and I can reproduce both with Chromium and Chrome.

00:02.0 VGA compatible controller: Intel Corporation Broadwell-U Integrated Graphics (rev 09) (prog-if 00 [VGA controller])
	Subsystem: ASUSTeK Computer Inc. Device 181d
	Flags: bus master, fast devsel, latency 0, IRQ 49
	Memory at f6000000 (64-bit, non-prefetchable) [size=16M]
	Memory at e0000000 (64-bit, prefetchable) [size=256M]
	I/O ports at f000 [size=64]
	Expansion ROM at <unassigned> [disabled]
	Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit-
	Capabilities: [d0] Power Management version 2
	Capabilities: [a4] PCI Advanced Features
	Kernel driver in use: i915

For KDE one can use "Tearing prevention ("vsync")" = "Full screen repaints" in "Display & Monitor -> Compositor settings" as a workaround

On arch (gnome 3.16), the CLUTTER_PAINT solution stops partial repainting but causes the entire window not to repaint. The only solution for me is to not maximize chrome.

+1 on Comment 25. This solves the issue for me on Fedora 23. Thank you very much!

+1 for comment #29 works for me on Fedora 23

As reported @ https://code.google.com/p/chromium/issues/detail?id=516679

Starting Chrome 47 with --use-virtualized_gl_contexts=0 prevents the issue from occurring.

In Chrome 48 they added a patch to prevent Virtualized GL contexts on non-nvidia GPUs. https://code.google.com/p/chromium/issues/detail?id=514510#c37

I am experiencing this issue, but the problems are not limited to Chrome. For example, 2 glxgears does not work at the same time, one shows a blank window or still picture meanwhile reports high FPS rates at the console output.

I have tried the following workarounds without success:
- set CLUTTER_PAINT
- kwin "Full screen repaints"
- Chrome 47 with --use-virtualized_gl_contexts=0
- Chrome 48

with success:
- suspend composition on Plasma (alt+shift+f12)
- fall back to UXA

i3-4160 CPU, Fedora 22, Plasma Desktop. 100% reproducible.

UXA definitely fixes every glitches with XGL applications.

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xorg/driver/xf86-video-intel/issues/64.