Rerouting since it appears to be a paint issue.

@Reporter : Thanks for filing the issue.Could you please provide us any sample html file with above CSS file to triage the issue from test team end.

Thank You!

I've Attached a sample HTML document.

I had both colleagues who reported this to me test the sample document on their machines and the issue was observed immediately upon load.

Again the specs for the machines where we can see this occur:

MacBook Pro (Retina, 13-inch, Early 2015)
Sierra 10.12.4
Processor: 2.7 Ghz Intel Core i5
Memory: 16 GB
Graphics: Intel Iris Graphics 6100 1536MB

Deleted: paint-failure-sample.html 3.5 KB

paint-failure-sample.html 3.5 KB View Download

Thank you for providing more feedback. Adding requester "rbasuvula@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Given the "Sierra 10.12.4" (and Intel graphics) commonality, I wonder if this could be related to all other weirdness observed on this particular version of macOS ( issue 710208 ,  issue 710274 )

Any information the GPU team can provide about failures on Mac 10.12.4 with the above specs woudl be helpful. We're seeing lots of bugs from these machines, as fs@ indicates in comment #6.

And thanks to the original reporter for the excellent analysis.

+some Skia GPUers

Based on screenshots, the corrupted tile size is the same as the SkPictureShader tile size (we tile these gradients using picture shaders).

This seems to indicate the corruption occurs in Skia's picture shader texture.

 Issue 711639  has been merged into this issue.

I can repro locally. From what I can tell, this happens when you have chunks of a gradient that are fully transparent. This makes me suspect something along the lines of Skia optimizing the fully-transparent part of the gradient to a no-op, but not clearing the underlying texture?

I believe this is unrelated to the issues mentioned in #6.

In case you want extra data points, I just found this bug occurring on a gradient-heavy project: https://gilmoreorless.github.io/

There are two repeating backgrounds that occasionally show the same rendering glitch (see screenshots).

It fails on my personal laptop:

Chrome 57.0.2987.133 (64-bit), 58.0.3029.81 (64-bit) and 60.0.3078.0 Canary (64-bit)
MacBook Pro (Retina, 13-inch, Early 2015)
Sierra 10.12.4
Processor: 2.9 GHz Intel Core i5
Memory: 16 GB
Graphics: Intel Iris Graphics 6100 1536MB


But it works every time on my work laptop. Same age model and same OS, but different screen size, CPU and graphics card:

Chrome 58.0.3029.81 (64-bit)
MacBook Pro (Retina, 15-inch, Mid 2015)
Sierra 10.12.4
Processor: 2.5 GHz Intel Core i7
Memory: 16 GB
Graphics: AMD Radeon R9 M370X 2048MB

Screenshots and reduced test case HTML file attached. The bug is never consistent for me, and often appears or vanishes when resizing the window.

Deleted: gilmoreorless-gradient-render-weirdness-01.png 143 KB

	gilmoreorless-gradient-render-weirdness-01.png 143 KB View Download

Deleted: gilmoreorless-gradient-render-weirdness-02.png 837 KB

	gilmoreorless-gradient-render-weirdness-02.png 837 KB View Download

Deleted: crbug710443-test.html 2.1 KB

crbug710443-test.html 2.1 KB View Download

@ericrk what hw are you able to repro on?  Sounds like an Iris 6100 specific problem so far, and as an extra data point I cannot repro on a 2016 MBP w/ Intel HD 530.

Also, do you mind double-checking the bisect in  issue 711639 ?  If accurate, the only suspicious thing I see there is https://codereview.chromium.org/1941353003 from the Skia roll.  Maybe you can try a quick revert and see if it makes a difference.

This also happens on Intel HD 6000.

Regarding the bisect in  issue 711639 : it probably is incorrect. When I tried to check it on a notebook with HD 6000, the results were different - the issue was present in much older revisions. So, either there are several different bugs with different hardware specifics, or that bisect was wrong (I can not recheck now). Sorry for not posting this before.

@ahest thanks!  I figured this must be tricky to bisect accurately, because of the flakiness factor.

Re #13 - my repro was also on an intel 6100. I'll try to re-bisect.

No luck re-bisecting, on my machine it seems to appear around 402925, which is already later than the changes where ahest@ saw it on his machine... guessing that different uses of the GPU just cause it to become more/less flaky at certain points.

I've came across same issue described in this thread last night.
Video : https://www.youtube.com/watch?v=WLUfCtJIzok
Some screen shots(in thread) : https://twitter.com/kosamari/status/857055566144970753

It seems to happen everywhere on the web that has patterned background like
https://caniuse.com/
https://www.bustle.com/

On Macbook Air Early 2015
OS Sierra v10.12.4
GPU Intel HD Graphics 6000 1536 MB
Chrome Version 58.0.3029.81 (64-bit)
(also happens on chrome Version 60.0.3080.5 (Official Build) canary)

Can confirm and reproduce on:

MacBook Pro (Retina, 13-inch, Early 2015)
OS Sierra 10.12.4 (16E195)
Intel Iris Graphics 6100 (1536MB)

Chrome Versions: 
Version 58.0.3029.81 (64-bit)
Version 60.0.3082.0 (Official Build) canary (64-bit)

Maybe related to transparent patterned backgrounds with linear gradients in pseudo-elements?

 Issue 710725  has been merged into this issue.

 Issue 707591  has been merged into this issue.

This seems to be affecting a fair number of users - feels high priority. Can someone from Skia please take a look? This should be easy to reproduce on 2015 MBPs using Intel Graphics - Iris 6100, HD Graphics 6000 (Maybe Iris Pro 62000).

Might be a driver issue, but hopefully one we can work around - it seems like we aren't clearing the SkPictureShader tile textures before using them in raster (or we are clearing, but the driver is dropping the result).

If there's an area of code you think needs to be experimented with, but don't have hardware to repro, let me know what to try and I can run some tests.

Brian, does anyone in your team have the hw to investigate this?

here is the chrome://gpu dump from one of the laptops at our office exhibiting this problem.

Deleted: chrome-gpu-dump.txt 7.5 KB

chrome-gpu-dump.txt 7.5 KB View Download

FYI The system in #24 is an HD 6000, so still seems to be 8th gen Intel GPUs used in ~2015 Macs.

Jim might have a laptop that can repro this at home. Otherwise, we will need to buy/borrow one.

We don't have one of these laptops. Eric, can you try one thing for me before I try to buy one of these?

Could you add "fUseDrawInsteadOfClear = true;" here

https://cs.chromium.org/chromium/src/third_party/skia/src/gpu/gl/GrGLCaps.cpp?q=GrGLCaps.cpp+package:%5Echromium$&dr&l=517

?

Maybe you can get a suitable machine without leaving the office.  I can reproduce this on my Google corp laptop.  It's a MacBookAir7,2 "MacBook Air (13-inch, Early 2015)", Intel HD Graphics 6000 1536 MB, running macOS 10.12.4 (16E195) and Chrome 58.0.3029.81.

This bug shows up when I go to https://developer.mozilla.org/en/docs/Web/JavaScript/Guide/Functions and scroll down to the pink patterned box containing the text "square is hoisted".  I first noticed it on an external monitor, but even after unplugging the monitor the same problem occurs.  Sometimes the problem isn't obvious unless I select some text in that box.

I'm in a fairly small office and no one here seems to have a machine that would reproduce this. However, I have ordered one that should be here tomorrow.

bsalomon@, the fix you suggested in #27 does appear to prevent the issue. Let me know if there's anything else you'd like me to try. Thanks!

I received a machine on Friday. I have it setup to build Chrome. Unfortunately, it went to sleep over the weekend because I left the power settings as default so the build didn't complete. I'm now a few hours away from build completion.

I'm able to reproduce this on the machine with M58 stable on https://gilmoreorless.github.io fairly consistently. However, it doesn't seem to repro using my debug build at tip of tree some time last Friday.

It does occur on Canary so maybe it only happens in Release. I now have goma working on the laptop so I should be able to iterate faster.

Here is a somewhat minimized repro. It creates a texture, attaches it to a framebuffer object, clears the framebuffer using glClearColor(0,0,0,1). It then creates a second texture with its own FBO and draws the first texture into it and reads back from this second texture. On an affected GPU the color read back is all zeros (the alpha is zero instead of 1).

Reading back from the first texture before the draw to the second texture fixes this. As does changing the clear color (including changing it to glClearColor(0.00001, 0.00001, 0.00001, 1) or glClear(0, 0, 0, .99999)). It still repros when there are draws to the first fbo after the clear.

The original Skia "gm" test that I made this repro from does draw to the first fbo after clearing. The result is that the correct background appears in blocks around pixels affected by the draws. I'm speculating that there is some kind of framebuffer compression bug specific to opaque black and that the blocks that are hit by the draws are decompressed correctly when blended but that the blocks that are decompressed when textured from are not.

Deleted: sample.mm 9.7 KB

sample.mm 9.7 KB Download

I have written a workaround for Skia but it is insufficient to fix the bug as there are clears to opaque black that aren't coming from Skia.

My workaround was to turn glClearColor(0, 0, 0, 1) into glClearColor(0, 0, 0, 1.001)

I did an extremely hacky version of this in the command buffer and it resolves the bug:
https://codereview.chromium.org/2879593003

I'm not sure who to pass this baton to so assigning to Victor for reassignment.

I filed radar 32137547 with Apple about this issue.

I'll put together a cmd buffer workaround based on bsalomon's patch.

Adding some Intel folks in case they have any thoughts on this. bsalomon@ filed a radar and put together a sample app (see comment #34 and #36). Wanted to see if you had ideas on whether the glClearColor(0, 0, 0, 1) case is the only one we need to handle, or if this bug might show up in other cases.

Thanks!

The issue here is actually not just with opaque black (0,0,0,1) but with any glClearColor using only 0s and 1s. It seems like we're hitting some sort of clear fastpath, which likely doesn't trigger the clear in all necessary cases.

I'm updating the Skia workaround to address this (that alone fixes the reported issues), but we should follow up with a generic command buffer workaround.

https://skia-review.googlesource.com/c/17327/

Based on bsalomon@'s sample.mm app, I found that adding 'glFlush()' after 'glClearColor(0, 0, 0, 1); glClear(GL_COLOR_BUFFER_BIT);' can also fix it and don't need to change the alpha value. But this method may bring some perf loss. I wonder if there are also some sync problem. 

And we have reported this issue to our driver team. 

The following revision refers to this bug:
  https://skia.googlesource.com/skia/+/aeaf22bb0764c2a1b828d5f84f964ad77dce49b7

commit aeaf22bb0764c2a1b828d5f84f964ad77dce49b7
Author: Eric Karl <ericrk@google.com>
Date: Fri May 19 15:01:03 2017

Updated workaround for Intel 6xxx clear to 0/1 bug

The previous workaround only handled the glClearColor(0,0,0,1) case,
it turns out we need to work around any glClearColor made up of entirely
0s and 1s.

R=bsalomon@google.com
Bug:  710443 
Change-Id: I78a75559fc11811ad9a218436231354d66d2ad51
Reviewed-on: https://skia-review.googlesource.com/17327
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: Eric Karl <ericrk@chromium.org>

[modify] https://crrev.com/aeaf22bb0764c2a1b828d5f84f964ad77dce49b7/src/gpu/gl/GrGLGpu.cpp
[modify] https://crrev.com/aeaf22bb0764c2a1b828d5f84f964ad77dce49b7/src/gpu/gl/GrGLCaps.h
[modify] https://crrev.com/aeaf22bb0764c2a1b828d5f84f964ad77dce49b7/src/gpu/gl/GrGLCaps.cpp

Issue 715342 has been merged into this issue.

Does this need to be merged into 59?

The fix is not in M59. Requesting a merge. This is a very safe change for a pretty significant rendering issue that could affect many users. I believe the worst case problem of cherry picking is discovering that the driver bug workaround doesn't entirely fix the issue (though as of now we believe it does).

This bug requires manual review: We are only 13 days from stable.
Please contact the milestone owner if you have questions.
Owners: amineer@(Android), cmasso@(iOS), gkihumba@(ChromeOS), Abdul Syed@(Desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Has this been already tested in canary? And is there enough unit test coverage?

It has been in canary for several days. There are tests that cover this. However, this is a platform-specific bug and we don't currently have a bot that would have reproduced the bug in our test lab. (We are working on increasing our Mac coverage in the Skia lab)

Ok thanks for providing more details. Approving merge for M59 based on comment 45 and 48. Please go ahead and merge for 3071.

FWIW I've just updated to the latest canary (60.0.3108.0 for reference) and I am no longer seeing the bug on the sites I'd previously tested.

Brian, can you take care of the merge, I'm ooo. Thanks!

The following revision refers to this bug:
  https://skia.googlesource.com/skia/+/bc5b838962015a256ead11b4604ac20b3a2ee8c6

commit bc5b838962015a256ead11b4604ac20b3a2ee8c6
Author: Brian Salomon <bsalomon@google.com>
Date: Wed May 24 00:22:53 2017

Updated workaround for Intel 6xxx clear to 0/1 bug

The previous workaround only handled the glClearColor(0,0,0,1) case,
it turns out we need to work around any glClearColor made up of entirely
0s and 1s.

R=bsalomon@google.com
Bug:  710443 
Change-Id: I78a75559fc11811ad9a218436231354d66d2ad51
Reviewed-on: https://skia-review.googlesource.com/17327
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: Eric Karl <ericrk@chromium.org>

Workaround for Intel 6xxx clear to opaque black bug
NOTREECHECKS=true
NOTRY=true
NOPRESUBMIT=true
Bug: skia:
Change-Id: Id5e29b483c2b6f698219abfc5bbb2d858c4fc117
Reviewed-On: https://skia-review.googlesource.com/16427
Commit-Queue: Brian Salomon <bsalomon@google.com>
Reviewed-By: Brian Osman <brianosman@google.com>
Reviewed-on: https://skia-review.googlesource.com/17790
Reviewed-by: Brian Salomon <bsalomon@google.com>

[modify] https://crrev.com/bc5b838962015a256ead11b4604ac20b3a2ee8c6/src/gpu/gl/GrGLUtil.cpp
[modify] https://crrev.com/bc5b838962015a256ead11b4604ac20b3a2ee8c6/src/gpu/gl/GrGLUtil.h
[modify] https://crrev.com/bc5b838962015a256ead11b4604ac20b3a2ee8c6/src/gpu/gl/GrGLGpu.cpp
[modify] https://crrev.com/bc5b838962015a256ead11b4604ac20b3a2ee8c6/src/gpu/gl/GrGLCaps.h
[modify] https://crrev.com/bc5b838962015a256ead11b4604ac20b3a2ee8c6/src/gpu/gl/GrGLCaps.cpp

The fix is merged into Skia's M59 branch. The next build will pick it up.

 Issue 722831  has been merged into this issue.

 Issue 720934  has been merged into this issue.

There is an update on the radar bug. The glClear issue is fixed in a driver update to OS 10.12.4 (driver 10.25.17) and in OS 10.12.5.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/01aa041da4c2327324ae3470c8e29f4829a9e928

commit 01aa041da4c2327324ae3470c8e29f4829a9e928
Author: jiajia.qin <jiajia.qin@intel.com>
Date: Wed Jul 12 23:36:05 2017

Workaround for Intel 6xxx clear to 0/1 bug

This is ported form skia fixing https://skia-review.googlesource.com/c/17327/
and https://skia-review.googlesource.com/c/16427/

BUG= 710443 
TEST=WebGL conformance test:framebuffer-texture-clear.html
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.android:android_optional_gpu_tests_rel;master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel

Review-Url: https://codereview.chromium.org/2934733002
Cr-Commit-Position: refs/heads/master@{#486150}

[modify] https://crrev.com/01aa041da4c2327324ae3470c8e29f4829a9e928/gpu/command_buffer/service/gles2_cmd_decoder.cc
[modify] https://crrev.com/01aa041da4c2327324ae3470c8e29f4829a9e928/gpu/config/gpu_driver_bug_list.json
[modify] https://crrev.com/01aa041da4c2327324ae3470c8e29f4829a9e928/gpu/config/gpu_driver_bug_workaround_type.h
[modify] https://crrev.com/01aa041da4c2327324ae3470c8e29f4829a9e928/ui/gl/BUILD.gn
[modify] https://crrev.com/01aa041da4c2327324ae3470c8e29f4829a9e928/ui/gl/gl_context.cc
[modify] https://crrev.com/01aa041da4c2327324ae3470c8e29f4829a9e928/ui/gl/gl_context.h
[modify] https://crrev.com/01aa041da4c2327324ae3470c8e29f4829a9e928/ui/gl/gl_gl_api_implementation.cc
[modify] https://crrev.com/01aa041da4c2327324ae3470c8e29f4829a9e928/ui/gl/gl_gl_api_implementation.h
[add] https://crrev.com/01aa041da4c2327324ae3470c8e29f4829a9e928/ui/gl/gl_workarounds.h