Looks like I issued a duplicate of this, here: https://bugs.chromium.org/p/chromium/issues/detail?id=768207

There's also an older, related issue: https://bugs.chromium.org/p/chromium/issues/detail?id=767842

Kb

Able to reproduce the issue on mac 10.12.6 and Windows 10 using chrome reported version #61.0.3163.100 and latest canary #63.0.3223.0.
Issue is not seen in OS-Linux.

Bisect Information:
=====================
Good build: 61.0.3163.43
Bad Build : 61.0.3163.44

Note: Both good and bad builds are branch builds. Hence, got the change log from omahaproxy.

Change Log URL: 
https://chromium.googlesource.com/chromium/src/+log/61.0.3163.43..61.0.3163.44?pretty=fuller&n=10000

From the above change log suspecting below change
Change-Id: Ic651c35e1ce865f3008dd345952a6fbc97d94740
Reviewed-on: https://chromium-review.googlesource.com/596503

enne@ - Could you please check whether this is caused with respect to your change, if not please help us in assigning it to the right owner
Note: Adding label ReleaseBlock-Stable as it seems to be a recent regression. Please feel free to remove the same if not appropriate.

Thanks...!!

 Issue 767842  has been merged into this issue.

 Issue 768207  has been merged into this issue.

I think this patch has been in long enough that if this issue were triggered on more sites that we would have seen issues before now.  I'll investigate and try to fix, but I don't think it's stable release blocking.

I cannot repro this on a Mac at ToT chromium (r504101).

Can you attach your about:gpu and additionally try to reproduce with turning off gpu rasterization in about:flags?

Also cannot repro on canary 63.0.3223.0 on a Mac.  Seems like it might be hardware/driver-specific.

 Issue 766723  has been merged into this issue.

cvermeul@gmail.com or krajshree@chromium.org, could either of you attach the contents of chrome://gpu to this bug, and to try reproducing when gpu rasterization is turned off in chrome://flags?

Galaxy

 Issue 770672  has been merged into this issue.

Hi enne@chromium.org thank you for looking at this issue, with the GPU rasterization turned off the rendering works fine. I joined my chrome://gpu as attachment

Deleted: gpu.html 52.4 KB

gpu.html 52.4 KB View Download

robertphillips: bsalomon hasn't been around for a bit.  Can you look into this hardware specific gpu raster bug? It seems pretty similar to  issue 755871 , but also happens on Mac, so isn't the same angle d3d11 clearing work around.

Adding M-62 label for tracking purpose.

On Oct 4, 2017 9:28 PM, wrote:

I've been able to reproduce the bug on a Windows Z620 machine w/ an nVidia Quadro K620.

I have attached the skp.

The bug also reproduces when rendering the skp file stand-alone in Skia. However it only repros for the D3D11 ES2 & ES3 configs. The D3D9 ES2 and OpenGL configs look fine.

Deleted: bug768134.skp 1.5 KB

bug768134.skp 1.5 KB Download

Here is a minimal repro in Skia code (suitable for https://fiddle.skia.org):

        SkPaint paints[2];
        paints[0].setColor(SK_ColorGREEN);
        paints[1].setColor(SK_ColorGRAY);

        const SkRect topRow[2] = {
            { 58, 26, 158, 51 },
            { 158, 26, 283, 51 },
        };

        for (int i = 0; i < 2; ++i) {
            canvas->saveLayer(&topRow[i], nullptr);
//            canvas->saveLayer(nullptr, nullptr);
                canvas->drawRect(topRow[i], paints[i]);
            canvas->restore();
        }

Note that the bounds parameter to saveLayer seems to be required to repro the bug. The size of the rects/layers doesn't seem to matter - even larger ones reproduce the noise.

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

commit 3a9305383169524488cb84e9bd5dba95520c3ca7
Author: Robert Phillips <robertphillips@google.com>
Date: Thu Oct 05 11:31:03 2017

Always use draws instead of clears for ANGLE D3D11

At least for my repro case on a Z620 with an nVidia Quadro K620 and recent drivers, this eliminates the noise artifacts.

It appears that full target clears are broken in ANGLE D3D11.

Note I was never able to repro the bug in the D3D9 or openGL configs.

The bug reproed for both the ES2 and ES3 ANGLE D3D11 configs though.

Bug:  768134 
Change-Id: I68e5fa0dc5e84b31d1d01a1e4b86132ab12a2e09
Reviewed-on: https://skia-review.googlesource.com/55381
Reviewed-by: Greg Daniel <egdaniel@google.com>
Commit-Queue: Robert Phillips <robertphillips@google.com>

[modify] https://crrev.com/3a9305383169524488cb84e9bd5dba95520c3ca7/src/gpu/gl/GrGLCaps.cpp

I was not able to repro the issue on a MacPro w/ an AMD FirePro D500.

Rob, thanks for taking this! Is it possible this fixes this bug as well: https://bugs.chromium.org/p/chromium/issues/detail?id=768207

I suspect it will. I was going to wait until the CL made into a Canary and then ping the entire chain of bugs to see if it fixes things.

The repro case for that bug in particular ( crbug.com/768207 ) is a bit more involved.

FWIW, this bug does not repro on an nVidia Quadro K2100M (with a recent driver) - even in the D3D11 configs.

So the "fix" in https://skia-review.googlesource.com/55381 could, in theory, be narrowed down a bit. However, it seems like that would be intractable in practice.

I've managed to repro the MacOS version of this issue on a MacBook Pro w/ an integrated Intel Iris Pro (which matches the chrome://gpu/ settings of the OP).

It appears that, like the ANGLE D3D11 version of the bug, full screen clears aren't working in this driver.

Note that both of the repro'ing MacBook Pros appear to have recent OS updates (so the drivers should be as up-to-date as they're going to get).

The fix in #25 rolled into Chrome on 10/5 in https://chromium-review.googlesource.com/c/chromium/src/+/701325 at r506731.

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

commit a2fd62ac78aa6e961809ada994e9ae46ebf57c7d
Author: Robert Phillips <robertphillips@google.com>
Date: Thu Oct 05 17:45:34 2017

Use draws instead of clears on Macs w/ Intel Iris Pro GPUs

Bug:  768134 
Change-Id: Iebebb617208c0d8415bebef495c6ff02b17efd65
Reviewed-on: https://skia-review.googlesource.com/55800
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: Robert Phillips <robertphillips@google.com>

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

To summarize:

The ANGLE/Windows fix (#25) rolled into Chrome on 10/5 in https://chromium-review.googlesource.com/c/chromium/src/+/701325 at r506731.

The MacOS fix (#32) rolled into Chrome on 10/6 in https://chromium-review.googlesource.com/c/chromium/src/+/703496 at r506894.

Both fixes are in the 63.0.3234.0 canary. I have verified that the bug is fixed on both platforms in this version of the canary.

I'm requesting cherry picks back to M62 for both the Windows and MacOS fixes.

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

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

I could never reproduce this issue but your changes in canary resolved https://bugs.chromium.org/p/chromium/issues/detail?id=769290 for me, Windows 64-bit with Intel i7-4600U integrated graphics.

 Issue 769290  has been merged into this issue.

#35, thanks for the information! This bug is, unfortunately, going to manifest in a lot of seemingly unrelated places.

Confirmed with robertphillips@ - both #32 and #25 are safe merges and fixes have been verified in Canary based in #35 and #37. Approving merge to M62 (branch:3202)

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

commit 2ba011d972d25f8c7f7a9ab5efaf80263083d0b6
Author: Robert Phillips <robertphillips@google.com>
Date: Fri Oct 06 17:58:24 2017

[M62 cherry pick] Always use draws instead of clears for ANGLE D3D11

At least for my repro case on a Z620 with an nVidia Quadro K620 and recent drivers, this eliminates the noise artifacts.

It appears that full target clears are broken in ANGLE D3D11.

Note I was never able to repro the bug in the D3D9 or openGL configs.

The bug reproed for both the ES2 and ES3 ANGLE D3D11 configs though.

No-Tree-Checks: true
No-Try: true
No-Presubmit: true
Bug:  768134 
Change-Id: I68e5fa0dc5e84b31d1d01a1e4b86132ab12a2e09
Reviewed-On: https://skia-review.googlesource.com/55381
Reviewed-By: Greg Daniel <egdaniel@google.com>
Commit-Queue: Robert Phillips <robertphillips@google.com>
Reviewed-on: https://skia-review.googlesource.com/56600
Reviewed-by: Brian Salomon <bsalomon@google.com>

[modify] https://crrev.com/2ba011d972d25f8c7f7a9ab5efaf80263083d0b6/src/gpu/gl/GrGLCaps.cpp

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

commit 2909cc995e22df1e6226a2c5c10a6181a34fbf6f
Author: Robert Phillips <robertphillips@google.com>
Date: Fri Oct 06 19:00:21 2017

[M62 cherry-pick] Use draws instead of clears on Macs w/ Intel Iris Pro GPUs

No-Tree-Checks: true
No-Try: true
No-Presubmit: true
Bug:  768134 
Change-Id: Id5b66bee09fab5b7c8d6d64872f63153f0088566
Reviewed-on: https://skia-review.googlesource.com/56760
Reviewed-by: Brian Salomon <bsalomon@google.com>

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

The downside to the fix for this bug (i.e., using draws instead of clears) is a ~10% performance regression (skbug.com/7124). We might be able to reclaim some of this performance but definitely not all of it. However, I don't see that we have any choice but to take the performance hit and preserve correctness.

This bug (and a host of related issues) also manifests in M61.

Rejecting merge to M61 as we're not planning any further M61 releases for Desktop.

The Chrome-side perf regression associated with this work-around (i.e., replacing clears with draws in ANGLE/D3D) has appeared:  crbug.com/773045 .

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

commit a108c92ae5868ca99759a872edddb377f31ad1be
Author: Robert Phillips <robertphillips@google.com>
Date: Tue Oct 10 15:41:42 2017

Fix drawSpecialImage

W/o this fix the strict constraint on the specialImage draws can sometimes be removed. This CL ensures that the temporary SkImage always has the actual dimensions of the special Image.

Note: the replacement of full screen clears w/ draws revealed this bug b.c. the image filters were only drawing a rect for the content area of the special images. Thus when the final DAG result was drawn to the canvas some of the bleed through (from the removal of the strict constraint) was showing.

Bug:  755871 ,  768134 
skbug.com/7122

Change-Id: Id67b7143225c24b716e260c973f3bbf68f20188a
Reviewed-on: https://skia-review.googlesource.com/57660
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: Robert Phillips <robertphillips@google.com>

[modify] https://crrev.com/a108c92ae5868ca99759a872edddb377f31ad1be/include/private/GrRenderTargetProxy.h
[modify] https://crrev.com/a108c92ae5868ca99759a872edddb377f31ad1be/src/gpu/GrSurfaceProxy.cpp
[modify] https://crrev.com/a108c92ae5868ca99759a872edddb377f31ad1be/src/gpu/GrRenderTargetProxy.cpp
[modify] https://crrev.com/a108c92ae5868ca99759a872edddb377f31ad1be/include/private/GrSurfaceProxy.h
[modify] https://crrev.com/a108c92ae5868ca99759a872edddb377f31ad1be/src/image/SkImage_Gpu.cpp

The fix in #45 rolled into Chrome on 10/10 in https://chromium-review.googlesource.com/c/chromium/src/+/710163 at r507783. It does not appear to have made it into a Canary yet.

The fix in #45 has been running on the Chrome bots for 2 days and is in the 63.0.3237.0 (and above) Canaries.

I'm requesting a cherry-pick back to M62.

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

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

 Issue 760972  has been merged into this issue.

 Issue 771939  has been merged into this issue.

Thanks for the fix - I'm still uncertain whether this is truly a blocking bug. We are less than 4 days away from M62 Stable, and are considering only critical release blocking bugs. What is the full impact if we wait until M63 to fix this bug? 

Regarding comment #41, seems like there is a 10% performance regression if we merge the fix. Specifically which metrics will be impacted? +benhenry@ 

#39 and #40 have already landed in M62 - so M62 will already experience the perf regression.

The Chrome-side bug for the perf regression is in  crbug.com/773045  and might help quantify the extent of the perf problems. TL;DR is that we do a lot of clearing and using draws instead of clears is a lot slower.

#45, which is the fragment of the fix still not cherry-picked to M62, could wait. The circumstances in which can occur is a bit convoluted (e.g., applying an image filter to a non-power-of-two texture).

Note that the Mac version of this bug turned out to be larger than initially thought. The Skia CL https://skia-review.googlesource.com/c/skia/+/58580
(Force all Intel GPUs to use draws instead of clears on Macs) is waiting in the wings. It unfortunately didn't make the M63 branch so it will have to be cherry-picked back to M63 and, arguably, should be cherry-picked back to M62.

Based on the bug traffic related to these issues, it seems there are a decent number of users affected by these bugs, and there's no reasonable workaround. Under these circumstances I suspect the users in question would eat the perf regression in order to get correct rendering.

And as I understand it not everyone gets the perf regression. Am I wrong there?

I would agree with #53. We're getting bug reports close to every day about this issue. It's quite visible to our users. Conversely we very rarely get bug reports about performance regressions in chrome 😉

The perf regression will be pretty wide spread (Windows machines using ANGLE/D3D11 and, if https://skia-review.googlesource.com/c/skia/+/58580 is cherry-picked, all Macs with Intel GPUs).

The perf impact will depend on the individual pages however.

That said, the alternative are some pretty horrendous rendering artifacts so I believe, short-term, we are stuck with some performance regression. There are some things we can try to do to mitigate the impact but they will take more (developer) time and won't be cherry-pickable.

This is a pretty significant regression, but on a metric we don't look at as a primary metric for releasing. 

I'd normally say no to any cherry-picking as it's too late and risky in M62, but do we have a fix in mind? This is going to make us look horrible? Is there a wya we can roll back the functionality in M62 and fix for 63?

Adding benchmark owner to help us understand more about regression impact.

The most severe perf regressions seem to be on the transferFromImageBitmap. This will have no impact on production since it measures an API that is not yet being used (UMA count = 0).  It an API of the ImageBitmapRenderingContext interface, which we do not expect will get any usage until after we launch OffscreenCanvas.

So let's not worry too much about the perf regression for now.  I will mark the perf regression as a blocker for shipping the OffscreenCanvas feature.

#25 and #32 have already been merged to M62 (per approval in #38). Checking with robertphillips offline, #45 does not warrant a merge right now. Rejecting Merge-Request from #47 as it's not necessary right now. 

 Issue 774455  has been merged into this issue.

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

commit 2fb81c04d74973181208f4f33eb6be4d4bae0321
Author: Robert Phillips <robertphillips@google.com>
Date: Tue Oct 17 18:14:52 2017

Add unit test for clear bug

Bug:  768134 
Change-Id: Ifb5a0eaeb85a8f399204467c22d0845d630d0d3d
Reviewed-on: https://skia-review.googlesource.com/60562
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: Robert Phillips <robertphillips@google.com>

[modify] https://crrev.com/2fb81c04d74973181208f4f33eb6be4d4bae0321/tests/ClearTest.cpp

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

commit bcc8e9bf3f70fb4adab34f898abaec1035fb5efb
Author: Robert Phillips <robertphillips@google.com>
Date: Tue Oct 17 19:20:33 2017

Revert "Add unit test for clear bug"

This reverts commit 2fb81c04d74973181208f4f33eb6be4d4bae0321.

Reason for revert: Apparently no gpu can consistently perform a full screen clear

Original change's description:
> Add unit test for clear bug
> 
> Bug:  768134 
> Change-Id: Ifb5a0eaeb85a8f399204467c22d0845d630d0d3d
> Reviewed-on: https://skia-review.googlesource.com/60562
> Reviewed-by: Brian Salomon <bsalomon@google.com>
> Commit-Queue: Robert Phillips <robertphillips@google.com>

TBR=bsalomon@google.com,robertphillips@google.com

Change-Id: I88434e55e5391e858ee7c37873d74d71f0c5b69f
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug:  768134 
Reviewed-on: https://skia-review.googlesource.com/60684
Reviewed-by: Robert Phillips <robertphillips@google.com>
Commit-Queue: Robert Phillips <robertphillips@google.com>

[modify] https://crrev.com/bcc8e9bf3f70fb4adab34f898abaec1035fb5efb/tests/ClearTest.cpp

 Issue 773797  has been merged into this issue.

From  Issue 773797  this reproduces with NVIDIA driver 353.62 but not in later drivers. I'm not sure where when it stopped reproducing.

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

commit dbfecd06adeb03e9365f3539e113412c0b18785e
Author: Robert Phillips <robertphillips@google.com>
Date: Fri Oct 20 15:49:25 2017

Re-land unit test for clear bug (w/ AMD work-arounds)

Bug:  768134 
Change-Id: I76e5e3ff5719b0d2f9c74d49dfa9e187e4da7c1f
Reviewed-on: https://skia-review.googlesource.com/60562
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: Robert Phillips <robertphillips@google.com>
Reviewed-on: https://skia-review.googlesource.com/61221

[modify] https://crrev.com/dbfecd06adeb03e9365f3539e113412c0b18785e/src/gpu/gl/GrGLUtil.cpp
[modify] https://crrev.com/dbfecd06adeb03e9365f3539e113412c0b18785e/src/gpu/gl/GrGLUtil.h
[modify] https://crrev.com/dbfecd06adeb03e9365f3539e113412c0b18785e/tests/ClearTest.cpp
[modify] https://crrev.com/dbfecd06adeb03e9365f3539e113412c0b18785e/src/gpu/gl/GrGLCaps.cpp

The initial symptoms are patched and we have the perf regression bugs to drive improvement of the work around so I am closing this.