The console is full of these warnings:

Active resource loading counts reached to a per-frame limit while the tab is in background. Network requests will be delayed until a previous loading finishes, or the tab is foregrounded. See https://www.chromestatus.com/feature/5527160148197376 for more details

but I think the real bug is here:

https://googlechromelabs.github.io/web-audio-samples/samples/audio/o3d-webgl/file_request.js

  // TODO(petersont): I think there is a race condition here -- calling
  // code expects that it can still set up the onreadystatechange callback
  // between open() and send(), but if open() actually initiates the XHR
  // then the caller may miss the crucial completion callback!


There may be a bug in the JavaScript port of O3D, but it's also possible this was affected by the resource throttling changes in Issue 729954.

I think both are not the root cause.

M68 w/chrome://flags/#enable-resource-load-scheduler Enabled works.

But, on M69, it does not work regardless of the flag enabled or disabled. Also, I haven't seen console warnings on all cases.

The race condition in the TODO mentioned in #c2 says it may happen if the resource loading finish immediately. So, throttling affects oppositely. Also, if callers set callbacks in a sequence, there is no race even though the callback is set after making actual request because callback handling happens later asynchronously, IIUC.

Another possible culprit is a DCHECK failure that I can see in TOT build. Here is a log. It reaches NOTREACHED(), https://cs.chromium.org/chromium/src/third_party/blink/renderer/platform/graphics/static_bitmap_image.h?q=static_bitmap_image.h&dr=CSs&l=83.

[1:1:0830/143359.739953:FATAL:static_bitmap_image.h(83)] Check failed: false.
#0 0x7f2bb60df39c base::debug::StackTrace::StackTrace()
#1 0x7f2bb600a1ab logging::LogMessage::~LogMessage()
#2 0x7f2bac124a89 blink::StaticBitmapImage::CopyToTexture()
#3 0x7f2bab9d35e3 blink::WebGLRenderingContextBase::TexImageCanvasByGPU()
#4 0x7f2bab9d3a1a blink::WebGLRenderingContextBase::TexImageByGPU()
#5 0x7f2bab9d42e6 blink::WebGLRenderingContextBase::TexImageHelperCanvasRenderingContextHost()
#6 0x7f2bab9d48f4 blink::WebGLRenderingContextBase::texImage2D()
#7 0x7f2bab485525 blink::V8WebGLRenderingContext::texImage2DMethodCallback()
#8 0x7f2baecaf764 v8::internal::FunctionCallbackArguments::Call()
#9 0x7f2baecade31 v8::internal::(anonymous namespace)::HandleApiCallHelper<>()
#10 0x7f2baecac278 v8::internal::Builtin_Impl_HandleApiCall()
#11 0x7f2baecabd11 v8::internal::Builtin_HandleApiCall()
#12 0x7f2baf995bf5 <unknown>

Thanks toyoshim@ for doing initial triage. I'll run a per-revision bisect on this tomorrow. Removing the Blink>Loader component for now.

Bisect results:
$ python bisect_builds.py --use-local-cache -o -a mac -g 561733 -b 587302 -- https://googlechromelabs.github.io/web-audio-samples/samples/audio/o3d-webgl-samples/pool.html

You are probably looking for a change made after 574613 (known good), but no later than 574614 (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/a875a2ea21d8a321295a11440c80af01bcf7fa86..f8b8872f2080130c2b5bdf026f32f46aad7598da

Oh dear. The CL which broke this was:

Refactor canvas code to centralize CanvasResourceProvider ownership
https://chromium-review.googlesource.com/1134182

Going to try to study that CL in more depth to see if some synchronization is obviously missing.

BTW, this demo does a lot of (not well optimized) work drawing images to many intermediate 2D canvases on the way toward uploading them to WebGL textures.

Really appreciate you looking in to this.  For me, it's not high priority as it's really old code that no one has touched in many years, and the web changes.

Even though as far as I can tell, the CanvasResourceProvider is producing an AcceleratedStaticBitmapImage just before this line:

https://cs.chromium.org/chromium/src/third_party/blink/renderer/modules/webgl/webgl_rendering_context_base.cc?type=cs&q=ToStaticBitmapImage&sq=package:chromium&g=0&l=5132

at this point, StaticBitmapImage::CopyToTexture is failing because it's actually got an UnacceleratedStaticBitmapImage at that point.

One of the 256x256 canvases that's allocated for chopping up the pool-ball texture is in unaccelerated mode, apparently because its source was some recorded drawing commands that came from another canvas, and the source of them was an image.

The fix will be to refactor and generalize WebGL's texture uploading code to more properly handle canvases and other image sources when the images are both accelerated and unaccelerated.

Before making this fix I'm trying to create a reduced test case and am struggling to reproduce the behavior of this demo.

Raising to P1, because it's unclear how much web content this change has broken. There are some other outstanding bug reports on Android with similar symptoms which could have the same root cause.

Figured it out. The original code was creating another temporary canvas through which the image was flipped vertically. Adding that into the rendering pipeline triggers the assertion failure. Here's a test (destined for the WebGL conformance suite) which reproduces the problem.

Deleted: canvas-teximage-after-drawimage.html 4.1 KB

canvas-teximage-after-drawimage.html 4.1 KB View Download

Let me remove 729954 from the blocked on list since now 729954 is going to be rolled out, and having a blocking issue is confusing :)

Fix out for review in https://chromium-review.googlesource.com/1217856 . New WebGL conformance test up for review in https://github.com/KhronosGroup/WebGL/pull/2706 .

Blocking  Issue 880760  which is a P1 targeted at M69. The fix has been structured for easy backporting to Chrome 70 and also 69.

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

commit 8f1cfedd2c724d69ad8086cda33917972cfe6171
Author: Kenneth Russell <kbr@chromium.org>
Date: Thu Sep 13 18:56:56 2018

Refactor WebGL texture uploading from DOM sources.

The current code was fragile, relying on only approximate answers
about whether a canvas was accelerated or not.

Refactor the upload paths for canvases and ImageBitmaps to properly
make the decision about whether to take the GPU or CPU based upload
path based on whether the resource they receive (usually an Image) is
texture-backed. Replace TexImageCanvasByGPU and TexImageBitmapByGPU
with a single TexImageViaGPU.

More refactorings are possible, and will be built on this. This CL is
being kept self-contained for backport to earlier releases.

Tested with new conformance test in
https://github.com/KhronosGroup/WebGL/pull/2706 .

Bug:  878545 
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: I8a2653ef9f4a0cc6a36ba381941f5c30c94a57d8
Reviewed-on: https://chromium-review.googlesource.com/1217856
Commit-Queue: Kenneth Russell <kbr@chromium.org>
Reviewed-by: Kai Ninomiya <kainino@chromium.org>
Cr-Commit-Position: refs/heads/master@{#591096}
[modify] https://crrev.com/8f1cfedd2c724d69ad8086cda33917972cfe6171/third_party/blink/renderer/modules/webgl/webgl_rendering_context_base.cc
[modify] https://crrev.com/8f1cfedd2c724d69ad8086cda33917972cfe6171/third_party/blink/renderer/modules/webgl/webgl_rendering_context_base.h

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

commit e8283216b8a3efb85abddd901e05c162425fa892
Author: Kenneth Russell <kbr@chromium.org>
Date: Thu Sep 13 22:51:02 2018

Refactor WebGL texture uploading from DOM sources.

The current code was fragile, relying on only approximate answers
about whether a canvas was accelerated or not.

Refactor the upload paths for canvases and ImageBitmaps to properly
make the decision about whether to take the GPU or CPU based upload
path based on whether the resource they receive (usually an Image) is
texture-backed. Replace TexImageCanvasByGPU and TexImageBitmapByGPU
with a single TexImageViaGPU.

More refactorings are possible, and will be built on this. This CL is
being kept self-contained for backport to earlier releases.

Tested with new conformance test in
https://github.com/KhronosGroup/WebGL/pull/2706 .

Bug:  878545 
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: I8a2653ef9f4a0cc6a36ba381941f5c30c94a57d8
Reviewed-on: https://chromium-review.googlesource.com/1217856
Commit-Queue: Kenneth Russell <kbr@chromium.org>
Reviewed-by: Kai Ninomiya <kainino@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#591096}(cherry picked from commit 8f1cfedd2c724d69ad8086cda33917972cfe6171)
Reviewed-on: https://chromium-review.googlesource.com/1226262
Reviewed-by: Krishna Govind <govind@chromium.org>
Cr-Commit-Position: refs/branch-heads/3551@{#7}
Cr-Branched-From: 08c03be7fdeabd63de8e4efca4c562a2f5a70ba9-refs/heads/master@{#590850}
[modify] https://crrev.com/e8283216b8a3efb85abddd901e05c162425fa892/third_party/blink/renderer/modules/webgl/webgl_rendering_context_base.cc
[modify] https://crrev.com/e8283216b8a3efb85abddd901e05c162425fa892/third_party/blink/renderer/modules/webgl/webgl_rendering_context_base.h

Requesting merge of 8f1cfedd2c724d69ad8086cda33917972cfe6171 to both M69 and M70 branches after Canary comes out tomorrow.

Thank you kbr@.

pls update bug with canary result tomorrow morning on version 71.0.3551.3 or higher.

The NextAction date has arrived: 2018-09-14

Able to reproduce the issue on Mac 10.13.6 on reported version 69.0.3497.57.

Verified the fix on Mac 10.13.6 and Ubuntu 17.10, as per comment#0 on latest chrome version #71.0.3551.3.
Attaching screenshot for reference.
Observed that the pool balls have colors and numbers like real pool balls.
Hence, the fix is working as expected.
Adding the verified labels.

Thanks...!!

Deleted: 878545(1).png 317 KB

	878545(1).png 317 KB View Download

I tested 71.0.3552.2 (Official Build) canary (64-bit) as well and it loads this demo properly as well as the new WebGL conformance test https://www.khronos.org/registry/webgl/sdk/tests/conformance/textures/misc/canvas-teximage-after-multiple-drawimages.html .

I think this is OK to merge.

Approving merge to M69 branch 3497 and M70 branch 3558 based on comments #23, #24 and per offline chat with kbr@. Pls merge now. Thank you.

That's M70 branch 3538, right?

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

commit 44e4cbed9b8a798d3c7aeff627c79057383a6361
Author: Kenneth Russell <kbr@chromium.org>
Date: Fri Sep 14 16:47:36 2018

Refactor WebGL texture uploading from DOM sources.

The current code was fragile, relying on only approximate answers
about whether a canvas was accelerated or not.

Refactor the upload paths for canvases and ImageBitmaps to properly
make the decision about whether to take the GPU or CPU based upload
path based on whether the resource they receive (usually an Image) is
texture-backed. Replace TexImageCanvasByGPU and TexImageBitmapByGPU
with a single TexImageViaGPU.

More refactorings are possible, and will be built on this. This CL is
being kept self-contained for backport to earlier releases.

Tested with new conformance test in
https://github.com/KhronosGroup/WebGL/pull/2706 .

TBR=kbr@chromium.org

(cherry picked from commit 8f1cfedd2c724d69ad8086cda33917972cfe6171)

Bug:  878545 
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: I8a2653ef9f4a0cc6a36ba381941f5c30c94a57d8
Reviewed-on: https://chromium-review.googlesource.com/1217856
Commit-Queue: Kenneth Russell <kbr@chromium.org>
Reviewed-by: Kai Ninomiya <kainino@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#591096}
Reviewed-on: https://chromium-review.googlesource.com/1226022
Reviewed-by: Kenneth Russell <kbr@chromium.org>
Cr-Commit-Position: refs/branch-heads/3538@{#404}
Cr-Branched-From: 79f7c91a2b2a2932cd447fa6f865cb6662fa8fa6-refs/heads/master@{#587811}
[modify] https://crrev.com/44e4cbed9b8a798d3c7aeff627c79057383a6361/third_party/blink/renderer/modules/webgl/webgl_rendering_context_base.cc
[modify] https://crrev.com/44e4cbed9b8a798d3c7aeff627c79057383a6361/third_party/blink/renderer/modules/webgl/webgl_rendering_context_base.h

The merge to M69 is non-trivial and I can't do it today, so I think we should skip it on that branch. It's unfortunate that this broke, but developers should ideally test with Chrome's beta channel and report bugs earlier.

Removing the Merge-Approved-69 label.

 Issue 880760  has been merged into this issue.

 Issue 883606  has been merged into this issue.

Thanks so much for looking into this and fixing it. The pool demo looks great now!

Able to reproduce the issue on Mac 10.13.3 using chrome reported version #69.0.3497.57.

Verified the fix on Mac 10.13.3 and Ubuntu 14.04 using Chrome version #70.0.3538.22 as per the comment #0.
Attaching screen shot for reference.
Observed that pool balls have colors and numbers like real pool balls.
Hence, the fix is working as expected. 
Adding the verified labels.

Thanks...!!

Deleted: Screen Shot 2018-09-19 at 16.31.37.png 779 KB

	Screen Shot 2018-09-19 at 16.31.37.png 779 KB View Download

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

commit c5c33db0ef72b22579db2b87ab2f938347a74de1
Author: Kenneth Russell <kbr@chromium.org>
Date: Thu Sep 20 22:01:48 2018

Roll WebGL 7ca87fb..6d2f3f4

https://chromium.googlesource.com/external/khronosgroup/webgl.git/+log/7ca87fb..6d2f3f4

Tbr: kainino@chromium.org
Bug:  563816 ,  878545 
Cq-Include-Trybots: luci.chromium.try:win_optional_gpu_tests_rel;luci.chromium.try:mac_optional_gpu_tests_rel;luci.chromium.try:linux_optional_gpu_tests_rel;luci.chromium.try:android_optional_gpu_tests_rel;luci.chromium.try:linux_angle_rel_ng;luci.chromium.try:win_angle_rel_ng
Change-Id: I8c8b57fef830f85f26b231a6a22576d8f9159e0f
Reviewed-on: https://chromium-review.googlesource.com/1225605
Reviewed-by: Kenneth Russell <kbr@chromium.org>
Reviewed-by: Yuly Novikov <ynovikov@chromium.org>
Commit-Queue: Kenneth Russell <kbr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#592964}
[modify] https://crrev.com/c5c33db0ef72b22579db2b87ab2f938347a74de1/DEPS
[modify] https://crrev.com/c5c33db0ef72b22579db2b87ab2f938347a74de1/content/test/gpu/gpu_tests/webgl_conformance_revision.txt

 Issue 889027  has been merged into this issue.