Did this work before? Yes

Based on the private message with reporter. It used to work on M65 stable.

Is there a hardware acceleration optimization for this 66 version of canvas2d, which feels like a z-fighting, stitching problem with openGl?

http://www.cnblogs.com/bitzhuwei/archive/2015/06/12/4571539.html

Deleted: WechatIMG63.jpeg 40.2 KB

	WechatIMG63.jpeg 40.2 KB View Download

Deleted: WechatIMG64.jpeg 74.5 KB

	WechatIMG64.jpeg 74.5 KB View Download

Able to reproduce this issue on 66.0.3359.139 using Macbook Pro Retina 10.13.3. Issue is not reproducible on Macbook Pro Retina 10.13.1 touchbar enabled, Macbook Air, Linux and Windows.

Good Build: 66.0.3347.0
Bad Build: 66.0.3348.0

You are probably looking for a change made after 536819 (known good), but no later than 536820 (first known bad).
CHANGELOG URL:
The script might not always return single CL as suspect as some perf builds might get missing due to failure.
  https://chromium.googlesource.com/chromium/src/+log/27b5ec64f45004c8a7c6d8d0e0c2f281ee237889..058b1a95f1d7b5cd89fa106746ee01c5250ff562

Reviewed-on: https://chromium-review.googlesource.com/907867

Suspecting same from changelog.

@ khushalsagar: Please confirm the bug and help in re-assigning if this is not related to your change. Adding RB-Stable for M-66. Please remove if not required.

Thanks!

Huh, all that change does is add a flush after a set of ops. I'll verify tomorrow if that change is actually the cause of this bug.

The bisect is correct, disabling context flushes does resolve the bug. But I have no clue why regularly flushing the context after a fixed set of ops would result in this.

+piman, Brian, ideas?

Nothing comes to mind. My best guess is that changing the flushes tickled a driver bug.

+zmo, kbr in case this looks familiar to some existing workaround.

Not on top of my head. We do have workarounds where glFlush solves some driver bug instead of causing one.

It sounds a little like what jdarpinian@ and sunnyps@ has been looking into in Issue 835353. Could the GPU service side be occasionally rendering incomplete frames because the additional flushes are points at which the GPU scheduler runs?

Flush should never cause different rendering, except if some synchronization is  missing (or, I guess, driver issues).

The other thing is, while some of these do look like z-fighting, but canvas doesn't use a z buffer, AFAIK?

Correct, Skia doesn't use the z buffer. Does anything else that is on the shared graphics context use the z buffer?

Re #15, no. That shared context doesn't support a z buffer (https://cs.chromium.org/chromium/src/content/renderer/render_thread_impl.cc?type=cs&g=0&l=368).

Sorry for the confusion; I only meant that the rendering corruption looked a little bit like z-fighting. Changing the summary again.

The only situation I know of where driver-level flushes could cause different rendering is a situation like Issue 828363 where the tiler's depth buffer is being resolved, spilled to and reloaded from main memory. That's certainly not the case here where the GPU isn't a tiled architecture.

It might be worth putting in a GrContext::resetContext() after each GrContext::flush() to see if it resolves a GL state issue.

Thanks for the suggestion Brian. That still didn't fix it...

As this is regressed in M66 stable and we're very close to M67 stable promotion,  we won't consider this as M67 Stable blocker. Pls let us know ASAP if there is any concern here. Thank you.

I have a patch up to disable these auto flushes on mac: https://chromium-review.googlesource.com/c/chromium/src/+/1059863, I'm not sure what driver bug is causing this.

Removing RB-stable. The bug is rare and doesn't need a merge to 67.

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

commit 2c5e4691552d261a2040296b6ddd48be611333b2
Author: Khushal <khushalsagar@chromium.org>
Date: Sat May 19 01:17:48 2018

blink/canvas2d: Don't auto-flush GrContext on mac.

This seems to result in corrupt rendering on some mac devices due to
driver issues.

R=junov@chromium.org

Bug:  841755 
Cq-Include-Trybots: luci.chromium.try:android_optional_gpu_tests_rel;luci.chromium.try:linux_optional_gpu_tests_rel;luci.chromium.try:mac_optional_gpu_tests_rel;luci.chromium.try:win_optional_gpu_tests_rel;master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.linux:linux_layout_tests_slimming_paint_v2
Change-Id: I8a74c0634f14f8e7f18a76243e013a47f39cee27
Reviewed-on: https://chromium-review.googlesource.com/1059863
Reviewed-by: Antoine Labour <piman@chromium.org>
Reviewed-by: Justin Novosad <junov@chromium.org>
Commit-Queue: Khushal <khushalsagar@chromium.org>
Cr-Commit-Position: refs/heads/master@{#560131}
[modify] https://crrev.com/2c5e4691552d261a2040296b6ddd48be611333b2/gpu/config/gpu_driver_bug_list.json
[modify] https://crrev.com/2c5e4691552d261a2040296b6ddd48be611333b2/gpu/config/gpu_workaround_list.txt
[modify] https://crrev.com/2c5e4691552d261a2040296b6ddd48be611333b2/third_party/blink/renderer/platform/graphics/DEPS
[modify] https://crrev.com/2c5e4691552d261a2040296b6ddd48be611333b2/third_party/blink/renderer/platform/graphics/canvas_resource_provider.cc

Able to reproduce this issue on build without fix, hence verifying the fix on latest canary 68.0.3436.0 using Macbook Pro Retina 10.13.3

Now on refreshing the page not observing any corruption. Hence fix is working as expected. Hence adding Verified labels.

Thanks!

Deleted: 841755_M68.mp4 1.8 MB

	841755_M68.mp4 1.8 MB View Download

I used the 68.0.3436.0 (official version) Canary (64 bit) test has indeed been fixed, thanks a lot