Please triage, thanks!

Olivia, can you please take this? The failures look legitimate and look like the canvas is occasionally coming out black:

https://ci.chromium.org/buildbot/tryserver.chromium.linux/linux_chromium_rel_ng/636798

http://chromium-browser-gpu-tests.commondatastorage.googleapis.com/view_test_results.html?a1df8ee7f1f3b13134e056ff1f4580ea2aa295ea_linux_chromium_rel_ng_telemetry

I'll temporarily disable the test on Linux and Android. It looks like it's flaking just on those platforms.

Forgot to do the actual bug updates I intended.

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

commit 89d19f291c8a471a7da51a6bf7bbb62e1b26adb3
Author: Kenneth Russell <kbr@chromium.org>
Date: Thu Feb 01 06:12:46 2018

Mark Pixel_OffscreenCanvasTransferToImageBitmap flaky on Linux and Android.

NOTRY=true
TBR=xlai@chromium.org

Bug:  807742 
Cq-Include-Trybots: master.tryserver.chromium.android:android_optional_gpu_tests_rel;master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel
Change-Id: I28ca7cadaf38000f08ee1c93f6170271666e9b73
Reviewed-on: https://chromium-review.googlesource.com/896838
Commit-Queue: Kenneth Russell <kbr@chromium.org>
Reviewed-by: Kenneth Russell <kbr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#533589}
[modify] https://crrev.com/89d19f291c8a471a7da51a6bf7bbb62e1b26adb3/content/test/gpu/gpu_tests/pixel_expectations.py

I'm trying to identify a potential culprit CL that's landed in end of January 
because the flakiness starts around that period of time, but could not find it.

The image blackout is very weird. At first I thought it is because of an unsuccessful attempt in prepareTransferableResource (https://cs.chromium.org/chromium/src/third_party/WebKit/Source/platform/graphics/gpu/DrawingBuffer.cpp?l=515) but after testing 
I realize that this is generating a transparent black image, not an opaque black image.
There are no other client-side code that generate opaque black image.

This problem is very similar to the other flaky OffscreenCanvas tests as in
https://bugs.chromium.org/p/chromium/issues/detail?id=735228 which involves
OffscreenCanvas.commit(), and we suspected
that the texture is just not available at the time when display compositor is
trying to access it, possibly a race condition. But the test in this particular
issue does not involve commit().

lowers priority because this issue pertains to an unshipped feature .

+cc danakj@ who've been working intensively on replacing TextureMailbox to TransferableResource. +cc junov@ for interest. Looking for help as I am unable to reproduce this issue
locally and can only dig into the code itself.

This issue is very similar to https://bugs.chromium.org/p/chromium/issues/detail?id=735228 where PixelIntegrationTest.Pixel_OffscreenCanvasTransfer*StyleResize are flaky.

The common function called by Pixel_OffscreenCanvasTransfer*StyleResize and Pixel_OffscreenCanvasTransferToImageBitmap is DrawingBuffer::TransferToStaticBitmapImage(). This calls DrawingBuffer::FinishPrepareTransferableResourceGpu in preparing a TransferableResource; previously it was using a gpu Mailbox but there was a recent switch to TransferableResource. Somehow, the image prepared in this OffscreenCanvas WebGL is not getting rendered and a black canvas is shown (not a transparent black canvas that's generated by client-side code), showing texture loss at the time of rendering. This fact that this issue is flaky shows that there is some race condition involved. 

The DrawingBuffer::PrepareTransferableResourceInternal() function was initially designed for TextureLayer; and it contains a release_callback that recycles the resources used. DrawingBuffer::TransferToStaticBitmapImage() directly takes this function to use and strangely, it does not call this release_callback at all; it looks like the resources in this
function is quite mal-managed.

>  DrawingBuffer::TransferToStaticBitmapImage() directly takes this function to use and strangely, it does not call this release_callback at all; it looks like the resources in this function is quite mal-managed.

I see it being returned in the out parameter of the method. https://cs.chromium.org/chromium/src/third_party/WebKit/Source/platform/graphics/gpu/DrawingBuffer.cpp?rcl=ee42e70e84955213a33f3d7b24bb02615935744b&l=538 Or called directly below.

> This calls DrawingBuffer::FinishPrepareTransferableResourceGpu in preparing a TransferableResource; previously it was using a gpu Mailbox but there was a recent switch to TransferableResource.

TextureMailbox (the old thing) and TransferableResource (the new thing) both hold a MailboxHolder - gpu::Mailbox, target, gpu::SyncToken. So this should be equivalent. There's a gpu::Mailbox and a gpu::SyncToken involved either way.

> Somehow, the image prepared in this OffscreenCanvas WebGL is not getting rendered and a black canvas is shown (not a transparent black canvas that's generated by client-side code), showing texture loss at the time of rendering. This fact that this issue is flaky shows that there is some race condition involved. 

That sounds like a sync token isn't being inserted or waited on appropriately.

"We do not need to wait on the sync token in |transferable_resource| since the mailbox was produced on the same |m_gl| context that we are using here."

https://cs.chromium.org/chromium/src/third_party/WebKit/Source/platform/graphics/gpu/DrawingBuffer.cpp?rcl=ee42e70e84955213a33f3d7b24bb02615935744b&l=525

This appears to be true still.

But the sync token given to AcceleratedStaticBitmapImage::CreateFromWebGLContextImage() is the one that was set inside the TransferableResource in PrepareTransferableResourceInternal().

That was before the call to CreateAndConsumeTextureCHROMIUM(). So waiting on that sync token won't guarantee that the texture_id https://cs.chromium.org/chromium/src/third_party/WebKit/Source/platform/graphics/gpu/DrawingBuffer.cpp?rcl=add5e181c71051d746370d2a017a7903c6b19b33&l=532 is valid. We'd need to make a new sync token to replace the other, after using the command buffer to make that texture id.

 Issue 829977  has been merged into this issue.

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

commit 88ce09b95a8289cf5ca0c27b5265ea5ad9f8ea96
Author: Kenneth Russell <kbr@chromium.org>
Date: Wed Apr 11 00:32:53 2018

Mark Pixel_OffscreenCanvasTransferToImageBitmap flaky on Windows.

Already marked flaky on Linux and Android.

NOTRY=true
TBR=xlai@chromium.org, trchen@chromium.org, ynovikov@chromium.org

Bug:  807742 
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;master.tryserver.chromium.win:win_optional_gpu_tests_rel
Change-Id: I883f6f0e21f20aebdff32071de29d4f02c477c72
Reviewed-on: https://chromium-review.googlesource.com/1006357
Commit-Queue: Kenneth Russell <kbr@chromium.org>
Reviewed-by: Kenneth Russell <kbr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#549696}
[modify] https://crrev.com/88ce09b95a8289cf5ca0c27b5265ea5ad9f8ea96/content/test/gpu/gpu_tests/pixel_expectations.py

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

commit 290d112f43196bcdda5ba3b22e9c6085c59bf245
Author: xlai <xlai@chromium.org>
Date: Wed Apr 18 17:14:41 2018

Add image release callback to TransferToImageBitmap

Bug:  807742 
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
Change-Id: I4b51cdc093f914ca05801b301e55be124d52c3a1
Reviewed-on: https://chromium-review.googlesource.com/1015649
Reviewed-by: Zhenyao Mo <zmo@chromium.org>
Commit-Queue: Olivia Lai <xlai@chromium.org>
Cr-Commit-Position: refs/heads/master@{#551726}
[modify] https://crrev.com/290d112f43196bcdda5ba3b22e9c6085c59bf245/content/test/gpu/gpu_tests/pixel_expectations.py
[modify] https://crrev.com/290d112f43196bcdda5ba3b22e9c6085c59bf245/third_party/blink/renderer/modules/webgl/webgl_rendering_context_base.cc

The test has been running for a few days. No flakiness is seen.

Thanks for fixing the flakiness in this test Olivia!