Able to reproduce the issue on the latest canary(55.0.2867.0) and the latest stable(53.0.2785.116) on Mac OS 10.11.6, same works fine on Windows 10 and Linux Ubuntu 14.04.

This is a regression issue broken in M-49.

Last good build: 49.0.2566.0
First bad build: 49.0.2567.0

Changelog: https://chromium.googlesource.com/chromium/src/+log/74f8c3c9cb1093bc7c8e88ff6334658b124ea0c8..aaf14fcb702dd2b733eaccb3307c54e18010fb71

Suspected change: https://codereview.chromium.org/1430813002

ccameron@: Could you please take a look at this.

Thank you!

I was wondering if this could be a paint invalidation bug where only the bounding rect of the drawn primitive was getting updated. So I tried an experiment by drawing a non fillRect primitive in order to get an update rect that is different from the primitive.

I tried changing the fillRect to a strokeRect in the fiddle, and the inside of the rect was initially white.  This means what we have is a compositing bug, not a paint invalidation bug.

The canvas in this example is in "display list" mode and the call to getImageData/toDataURL/toBlob causes the canvas to switch to software rendering mode.

In display list mode, the content of the canvas get rasterized by the compositor into a skia "saveLayer".  with the alpha:false option, we end up using the 'source' composite operation (as opposed to source-over) when painting the saveLayer onto its parent layer.  This step seems to be what is broken.  Al of this happen withing impl-side painting.

@ccameron: your change does not affect Impl-side painting AFAICT, but is it possible that it may be changing the GL state of the compositor's GL context in a way that interferes with ganesh?  Ganesh keeps it's own cache of the GL state in order to optimize-out unnecessary GL API calls. If ganesh's cached state falls out of sync with the GL context due to GL being used directly, ganesh needs to be notified (cache dirtied).  Do you think that could be it?

I see lots of flickering here. I also ran this without the CoreAnimation renderer enabled (which is related to that patch), and I still got flickering.

Of note is that the flickering is very flakey, so I'd be careful about trusting a bisect (or guarantees that it is Mac-specific).

Deleted: flicker.mov 987 KB

flicker.mov 987 KB Download

We see a potentially related issue here: http://stackoverflow.com/questions/40353969/html-canvas-silently-drops-frames-requestanimationframe

And here's a jsfiddle that occasionally shows some ghosting or partial draws on both Linux and OS X: https://jsfiddle.net/gdbsb564/7/

Had trouble reproducing in recent build.  Here is an updated fiddle that reproduces the problem more reliably by adding a delay before the first draw: https://jsfiddle.net/hbs4nyub/2/

In this case, even uncommenting one of the lines that triggers a software rendering fallback doe not fix the problem.  This is clearly a paint invalidation issue.

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

commit d9b157453d029d17966766dfcf7564fbc03d7c6e
Author: junov <junov@chromium.org>
Date: Thu Dec 08 02:11:17 2016

Add missing paint invalidation when creating canvas 2d context with no alpha

BUG= 647903 

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

[add] https://crrev.com/d9b157453d029d17966766dfcf7564fbc03d7c6e/third_party/WebKit/LayoutTests/fast/canvas/canvas-no-alpha-invalidation-expected.html
[add] https://crrev.com/d9b157453d029d17966766dfcf7564fbc03d7c6e/third_party/WebKit/LayoutTests/fast/canvas/canvas-no-alpha-invalidation.html
[modify] https://crrev.com/d9b157453d029d17966766dfcf7564fbc03d7c6e/third_party/WebKit/Source/core/html/HTMLCanvasElement.cpp

@junov, Glad you fixed it, does it also pass this test https://jsfiddle.net/kpkov098/ ? Because I found this this week-end and it would tend to say that it's not only a display bug, since at this point the display is ok, but the value returned by getImageData is not. (according to specs (https://html.spec.whatwg.org/multipage/scripting.html#output-bitmap), clearRect() should set the alpha bits to 255)

Right.  That is a separate bug. I filed it as issue 673416