I have a WIP fix.  It also fixes a bug that existed before the regression: the video is initially blank, and the teapot only appears once we start manipulating the canvas.

Should this be bumped to M59?

I intend to request a merge to 58 once the fix lands.  The fix is quite simple and safe, and the regression is pretty bad.

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

commit 7b09536cad07c7983eac63eac07ecf82f53c65d1
Author: junov <junov@chromium.org>
Date: Tue Mar 28 17:47:20 2017

Fix unreliable MediaStream capture from WebGL canvases

When capturing a MediaStrem from a WebGL canvas that
has the preserveDrawingBuffer option set to false, it is important
to perform the frame capture before the canvas is cleared by the
buffer swap mechanism.  This change resolves the issue by performing
the capture during the paint invalidation phase instead of during
frame finalization.  For canvases that are not visible on screen,
there is no paint invalidation, which is a problem. So in that
case, we fall back to doing the capture during frame finalization,
which is okay in that case because there is no buffer swap.

BUG= 702446 

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

[modify] https://crrev.com/7b09536cad07c7983eac63eac07ecf82f53c65d1/content/browser/webrtc/webrtc_capture_from_element_browsertest.cc
[modify] https://crrev.com/7b09536cad07c7983eac63eac07ecf82f53c65d1/content/test/data/media/canvas_capture_color.html
[modify] https://crrev.com/7b09536cad07c7983eac63eac07ecf82f53c65d1/third_party/WebKit/Source/core/html/HTMLCanvasElement.cpp
[modify] https://crrev.com/7b09536cad07c7983eac63eac07ecf82f53c65d1/third_party/WebKit/Source/core/html/HTMLCanvasElement.h

junov@ can we merge this fox to 58 as well?

@#8: Certainly, the fix is quite safe.

Your change meets the bar and is auto-approved for M58. Please go ahead and merge the CL to branch 3029 manually. Please contact milestone owner if you have questions.
Owners: amineer@(Android), cmasso@(iOS), bhthompson@(ChromeOS), govind@(Desktop)

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

Thanks for the fix, your change is approved for M58. Please merge ASAP so that it will be picked up for next Beta Release, RC cut on (Tuesday-04/04) at 4.00 PM PST.

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

commit d5af69c1ae0e600b758d1ae5dba6ead266826d13
Author: Justin Novosad <junov@chromium.org>
Date: Mon Apr 03 19:55:00 2017

Fix unreliable MediaStream capture from WebGL canvases

When capturing a MediaStrem from a WebGL canvas that
has the preserveDrawingBuffer option set to false, it is important
to perform the frame capture before the canvas is cleared by the
buffer swap mechanism.  This change resolves the issue by performing
the capture during the paint invalidation phase instead of during
frame finalization.  For canvases that are not visible on screen,
there is no paint invalidation, which is a problem. So in that
case, we fall back to doing the capture during frame finalization,
which is okay in that case because there is no buffer swap.

BUG= 702446 

Review-Url: https://codereview.chromium.org/2768683002
Cr-Commit-Position: refs/heads/master@{#460159}
(cherry picked from commit 7b09536cad07c7983eac63eac07ecf82f53c65d1)

Review-Url: https://codereview.chromium.org/2797543002 .
Cr-Commit-Position: refs/branch-heads/3029@{#553}
Cr-Branched-From: 939b32ee5ba05c396eef3fd992822fcca9a2e262-refs/heads/master@{#454471}

[modify] https://crrev.com/d5af69c1ae0e600b758d1ae5dba6ead266826d13/content/browser/webrtc/webrtc_capture_from_element_browsertest.cc
[modify] https://crrev.com/d5af69c1ae0e600b758d1ae5dba6ead266826d13/content/test/data/media/canvas_capture_color.html
[modify] https://crrev.com/d5af69c1ae0e600b758d1ae5dba6ead266826d13/third_party/WebKit/Source/core/html/HTMLCanvasElement.cpp
[modify] https://crrev.com/d5af69c1ae0e600b758d1ae5dba6ead266826d13/third_party/WebKit/Source/core/html/HTMLCanvasElement.h

Tested the issue on windows 7, Ubuntu 14.04 and Mac 10.12.3 using chrome version 58.0.3029.54 with the below steps

1. Go to URL https://webrtc.github.io/samples/src/content/capture/canvas-pc/
2. Observed initially the right side webgl is blank
3. The Teapot was displayed only after click and drag the left one.
4. Not observed any flickering effect while moving the teapot

Observed the same behaviour on builds 59.0.3046.0 and 58.0.3029.20.
junov@ could you please find the attached screen cast and confirm on the expected behaviour.

Thanks,

Deleted: 702446.mp4 933 KB

	702446.mp4 933 KB View Download

Hmmm... It should not be initially blank, but that is a minor issue (and not a regression) compared to the flickering problem.

I cannot repro the initial blank frame on Canary (59.0.3054.0) on Mac or on Ubuntu 14.04.  Did you observe this only on Windows?

Yes ,observed the same behaviour on mac 10.12.3 and Ubuntu 14.04 as well.
checked the issue on versions 59.0.3054.0 and current canary 59.0.3063.0 still seeing the blank frame initially.(attachment :: 59.0.3054.0 )

Observed one more thing If we open the page the very first time then the teapot loaded successfully.But if we reload the page or open the page again then the blank frame is coming.
Please find the attached screen shot to check this behaviour.(attachment :: 59.0.3063.0 )

Thanks,

Deleted: 59.0.3054.0.mp4 1.4 MB

	59.0.3054.0.mp4 1.4 MB View Download

Deleted: 59.0.3063.0.mp4 1.5 MB

	59.0.3063.0.mp4 1.5 MB View Download