Manual Bisect Range:
Good build:62.0.3177.0
Bad build:62.0.3178.0

Note: Above issue is not reproducible on Mac and Linux OS.

Deleted: Actual_video.mp4 428 KB

	Actual_video.mp4 428 KB View Download

Narrow bisect:
https://chromium.googlesource.com/chromium/src/+log/1441b968d8153d4d01345ad46264053f2513549a..e3d9eee91f3dfe5503bde5f3f4fc776e1552f857?pretty=fuller&n=10000

Suspecting: r491915 ?

Kindly help to re-assign, if your changes are not cause for this issue.

Adding blocker label, please undo if not the case.

pdr: looks like adding a clip to every compositing item was maybe not great.  Maybe visual rects are wrong? Or maybe I implemented this incorrectly?

I tried to repro this with pdr@ on a win device and we couldn't hit it there. I am not sure if there are any more repro steps because we didn't see a suggestion list pop up at all, even trying this on a stable build. Could you provide a bit more detailed instruction on how to repro this, and may be a video with the good/expected result.

We are branching in few days. Please have a fix ASAP.

Your bug is tagged as Release block Stable. 

M62 is branching soon and we will be taking only CRITICAL merges. Please plan accordingly.

abombde@ are you still hitting the issue?

abombde, do you have better repro instructions for this?

Update:

Rechecked this issue with steps mentioned in comment#0 on Windows (7,8,10) machines using build# 62.0.3199.0 and it is only reproducible on two machines, one is on Win-7 and another is Win-8. The same issue is not reproducible on other Win(7,8) machines and the frequency of occurrence of this issue is 3 out of 10.

Hi shruti.jadhav@etouch.net, can you help give us a little more information about this? I think you found a serious bug, I'm just having trouble reproducing it.

I tried this 10 times at various screen sizes and was not able to reproduce it. Can you try again with different screen sizes? Can you post a video of this happening again with a different screen size?

The patch you found caused this should affect all platforms. Can you try to see if you can get this to reproduce on a mac?

With response to comment #10 
The above issue is reproducible on Windows-7(Screen Resolution:1366 x 768)and Windows-8(Screen Resolution:1280 x 1024)and this issue in not seen on Mac OS.
Kindly refer the attached video for more reference.

@ Pdr : Please help to reassign this issue if your change is not cause for it.

Deleted: Actual_Result Windows-7_Resolution1366 x 768.mp4 1.4 MB

	Actual_Result Windows-7_Resolution1366 x 768.mp4 1.4 MB View Download

Deleted: Actual_video_Win_8_Resolution1280 x 1024.mp4 400 KB

	Actual_video_Win_8_Resolution1280 x 1024.mp4 400 KB View Download

Thank you, those videos are great.

I think this issue is related to a GPU-specific issue that Enne's change is affecting. We will try to find a machine that reproduces here.

shruti.jadhav, can you please post the information from "about:gpu" on those windows machines?

With respect to comment #12
I am sending you the GPU Information of Windows-7 and Windows-8 please kindly refer .
Thank You

Deleted: GPU_Info(Win-7).png 622 KB

	GPU_Info(Win-7).png 622 KB View Download

Deleted: gpu_info_Win_8.png 566 KB

	gpu_info_Win_8.png 566 KB View Download

Friendly ping for an update from enne@ on this.

Wasn't able to repro previously.  Am going to try to repro this week.

Can't repro on a win10 / intel hd 400 / 63.0.3206.0 / 1366x768 resolution computer no matter how much I tried.  Will try to dig up something with intel hd graphics 2500, which is what it looks like shruti reproed with.

shruti.jadhav, as an experiment, can you try testing with --disable-gpu-rasterization and see if that prevents the bug from showing up?

With respect to comment#17
Retested above issue on windows(7,8,10)OS with latest canary 63.0.3206.0 build and after disabling --disable-gpu-rasterization flag issue is not reproducible. Issue is only reproducible when the flag --disable-gpu-rasterization is enabled.

Thank you

I have an Ivy Bridge laptop with HD 4000 that reproduces this issue.

I ran biset-builds.py on the laptop to confirm the bisect since the repro is noisy. The range I got is this:

https://chromium.googlesource.com/chromium/src/+log/ab09b8194e..b7389d11bdd

which is contains just 11 revisions including the revision identified in #2.

The machine I was using had driver 10.18.10.3355 from 11/15/2013 on it when I was reproducing the bug. 

I tried the two driver versions available on Intel's website:

15.33.45.4563 from 5/23/2017 and
15.33.43.4425 from 5/13/2016

I could not repro on either.

On the old driver this reproduced with ANGLE D3D11 but not D3D9.

Jamie, do you think we should just blacklist D3D11 on older drivers? I can try more driver versions but I'm not sure where to get them from. This is where I got the two mentioned in #21:

https://downloadcenter.intel.com/product/81499/Intel-HD-Graphics-4000

Brian, I would strongly recommend putting in a blacklist entry for very old drivers. Specifically what date I'm not sure, maybe we can do quick check with metrics to see how many people are on old drivers, but definitely something from 2014 is too old, I'd even say anything prior to 2016 might be too old, but I'm not sure what % of our population has those drivers.

bsalomon@ Gentle Ping! Since this issue is marked as RB-Stable, could you please let us know is there any latest update available on this issue?

Thanks!

Moving driver bug version discussion from https://chromium-review.googlesource.com/c/chromium/src/+/667317 to here.

It seems that we want to be looking at the low number in Intel's versioning scheme as it corresponds to a build number whereas the upper numbers correspond to OS/D3D versions. Looking around on the Intel site it seems that some consist of 5 numbers, e.g. 15.36.24.64.4264 and others 4, e.g. 15.36.28.4332. AFAICT all versions that have 5 numbers have 64 as the fourth.

I don't know that gpu_driver_bug_list.json is expressive enough to do the type of check we'd need, though I could be wrong. It seems like ANGLE already has some sophistication around parsing Intel's driver versions. Is it possible to make the D3D11->D3D9 fallback happen in ANGLE?

I'm investigating whether there is a workaround that we can apply to keep D3D11 ANGLE enabled on these devices.

I grabbed a skp of the single layer on the page when the repro occurs and it does not reproduce when replayed on D3D11 ANGLE in Skia's viewer app.

I've noticed that on this laptop a Skia gm test that uses partial clears draws incorrectly. If I use solid color rect draws instead it passes. This seems like it could be related. I'm slowly building chrome on the system to test the theory...

Applying the clear-as-draw workaround in Chrome does fix this issue.

 Issue 766836  has been merged into this issue.

Thank you!

There is a wrinkle here, which is that Skia doesn't get enough information to deploy this workaround selectively based on driver version. We see the following strings:

RENDERER="ANGLE (Intel(R) HD Graphics 4000 Direct3D11 vs_5_0 ps_5_0)"
VERSION="OpenGL ES 2.0 Chromium"
VENDOR="Google Inc."
SHADING_LANGUAGE_VERSION="OpenGL ES GLSL ES 1.0 Chromium"


I'm planning to employ the workaround on all ANGLE D3D11 Ivy Bridge.

Can you describe the nature of this workaround? We may want to incorporate it into Chromium and ANGLE also.

Partial clears seem broken on this device. I believe Chrome & ANGLE already have mechanisms for working around such bugs. They just need to be turned on in this case.

The workaround in Skia is to draw a rectangle instead of clearing. I believe Chrome's gl_clear_broken workaround is similar. Skia's is implemented at a higher level in Ganesh so it is as though SkCanvas::drawRect() was called. In Skia this also turns off an optimization that turns some drawRects into clears.

Right, so far I've only seen instances where the clear extends outside the scissor rather than doesn't fill the scissor. So it should be possible to restrict the workaround to partial clears. We don't currently have code for that and this fix should be simple in order to cherry-pick.

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

commit 266ef6d72036fc2f7b9e42ad1126b8fe34da3d98
Author: Brian Salomon <bsalomon@google.com>
Date: Fri Sep 22 15:53:39 2017

Use clear-as-draw workaround on Ivy Bridge/ANGLE D3D11.

Bug:  chromium:755871 
Change-Id: Id2538406c75d86de994ff88cc0bfc17d2cb45394
Reviewed-on: https://skia-review.googlesource.com/50040
Commit-Queue: Brian Salomon <bsalomon@google.com>
Reviewed-by: Robert Phillips <robertphillips@google.com>

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

 Issue 763767  has been merged into this issue.

Does this need a merge to 62?

Even having rolled our reproducing device back to the 10.18.10.3355 I am no longer able to repro the bug in M62. So, I can't be sure this has been fixed.

The Skia fix rolled into Chrome at 503811 in https://chromium-review.googlesource.com/c/chromium/src/+/679036 on 9/22 and it looks like it made it into the 63.0.3223.1 build.

shruti.jadhav could you see if this is fixed in 63.0.3223.1?

With respect to comment #42
Retested the above issue on Windows(7,8,10)using build 63.0.3223.1 & 63.0.3227.0 and issue is still reproducible. Kindly refer the attached Screencast.
Thank you

Deleted: 63.0.3223.1.mp4 298 KB

	63.0.3223.1.mp4 298 KB View Download

I tried again today with our local machine and was able to repro the issue in 61.0.3163.100 and 62.0.3202.38 but not in 63.0.3225.0.

So, despite the failure to quash the repro in comment #43, I believe the current patch is fixing some bug - just maybe not the one being seen by the OP.

This bug requires manual review: M62 has already been promoted to the beta branch, so this requires manual review
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

Investigating a bit more, the CL in question (https://skia-review.googlesource.com/c/skia/+/50040) turns on the partial-clears-as-draws workaround for the "HD Graphics 2500" & "HD Graphics 4000". Unfortunately, there is also an IvyBridge "HD Graphics" category. Even more unfortunately, it appears Intel reuses this name for all their lowest end graphics cards so just disabling "HD Graphics" is a bit broad. 

The repro machine I have is "HD Graphics 4000" so the CL applies and things look good. The machine the OP has is plain "HD Graphics" so the CL doesn't apply.

One possible solution is to blacklist the GPU for IvyBridge "HD Graphics" at the Chrome level where there is more information available. Another option is to have ANGLE forward on more information about the GPU via the GL strings and then we could have a more precise check in Skia.

Per comment 46, seems like this issue is not resolved. Marking it as Merge-Rejected (please re-apply Merge-Request when fix is ready).

Upon clarification from robertphillips@ and re-reading #46, approving #38 for merge to M62 as it's still required. Confirmed that this is a safe merge and tested well in Canary. Branch:3202. 

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

commit fc6dd6fa4c2105bfd9d91f0a1ab0a17e398a291a
Author: Robert Phillips <robertphillips@google.com>
Date: Mon Oct 02 20:33:49 2017

[M62 cherrypick] Use clear-as-draw workaround on Ivy Bridge/ANGLE D3D11.

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

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

Retested this issue on Windows-(7,8,10) machines using latest Canary build # 63.0.3234.0 (Official Build) and latest Beta build # 62.0.3202.47 (Official Build). Fix is working as expected i.e. suggestion list seen properly.

Attaching screen-cast for the same.

Deleted: LatestCanary_behavior.mp4 1.5 MB

	LatestCanary_behavior.mp4 1.5 MB View Download

Deleted: LatestBeta_behavior.mp4 1.8 MB

	LatestBeta_behavior.mp4 1.8 MB View Download

This issue has been approved for a merge. Please merge the fix to any appropriate branches as soon as possible!

If all merges have been completed, please remove any remaining Merge-Approved labels from this issue.

Thanks for your time! To disable nags, add the Disable-Nags label.

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

This was merged to M62 in https://skia-review.googlesource.com/50102.

This P1 bug is also found in M61. It is also a forerunner for another batch of related bugs that all also appear in both M61 & M62.

In particular, the fix for the P1 bug  crbug.com/768134  relies on the fix for this bug.

In short, if we're going to want to cherry pick  crbug.com/768134  all the way back to M61 we will also need to cherry pick the fix for this P1 bug back to M61.

The fix has made it into the M62 Beta (62.0.3202.45)

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.

Note: the fix for this particular bug (https://skia-review.googlesource.com/50102) did not cause a visible performance regression b.c. Skia's waterfall doesn't have any Ivy Bridge bots.

We're not planning any further M61 release for Desktop, so rejecting merge to M61.

abdulsyed@ to decide whether to have this merge in for M62 or not. Please see comment #56 for details.

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

[Bulk Edit]
URGENT - PTAL.
M63 Stable promotion is coming soon and your bug is labelled as Stable ReleaseBlock, pls make sure to land the fix and get it merged into the release branch ASAP. Thank you.

The initial symptoms of this bug have been patched and we still have the perf bugs to drive improving the work around so I am closing this bug.