Input events stop when OffscreenCanvas under high load
Reported by
a...@scirra.com,
Jul 16
|
|||||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/69.0.3493.0 Safari/537.36 Steps to reproduce the problem: In our HTML5 game engine Construct 3 we are experimenting with hosting the entire engine in a Web Worker using OffscreenCanvas. A user discovered the following issue with OffscreenCanvas in worker mode. DOM test: https://www.scirra.com/labs/bugs/spritestressdom/index.html Worker test: https://www.scirra.com/labs/bugs/spritestressworker/index.html NOTE: this requires OffscreenCanvas to be enabled, which it is by default in the latest Canary builds. For each test try the following steps: 1. Load the URL in Canary 2. Hold down the left mouse button and wave the cursor around 3. Sprites are continually created while the left mouse button is down - keep creating sprites until the FPS starts to fall. What is the expected behavior? Input events should remain responsive even while the FPS is low due to high load in rendering work. What went wrong? With OffscreenCanvas in a worker, once there is a lot of content and the FPS starts to fall, input events first become intermittent. Eventually input events stop responding completely. The DOM version which just renders to a normal canvas on the main thread remains responsive even when the FPS is low. Did this work before? N/A Does this work in other browsers? N/A Chrome version: 69.0.3493.0 Channel: canary OS Version: 10.0 Flash Version: Since workers cannot receive input events directly, when our engine is hosted in a web worker, we add event listeners on the DOM and then postMessage() to the worker to forward input events to it. This seems to work fine as long as there is some idle time - it seems when there is a lot of work it stops getting events.
,
Jul 16
,
Jul 17
Just to update this. We have a solution for this already, but we are still waiting on some Scheduler folks to make sure that everything is fine.
,
Jul 17
Thanks for the quick investigation!
,
Jul 18
I think that the problem here is that mojo does not yield back to the scheduler and keeps running begin main frame tasks ((Impl)viz::mojom::CompositorFrameSinkClient::OnBeginFrame). I think that the proper fix is to process one mojo message per task and scheduler's anti-starvation logic should do the trick here.
,
Jul 20
,
Jul 23
The proper Mojo fix for this (https://chromium-review.googlesource.com/c/chromium/src/+/1145692) is going to take a while to land. Meanwhile, we are going to land (https://chromium-review.googlesource.com/c/chromium/src/+/1139188) and merge it.
,
Jul 23
,
Jul 23
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/ed98e25e2e6128cb6df6b3eb630b0572d2ef495f commit ed98e25e2e6128cb6df6b3eb630b0572d2ef495f Author: Fernando Serboncini <fserb@chromium.org> Date: Mon Jul 23 22:40:07 2018 Only execute Worker.RAF inside PostMessage taskrunner If a RAF takes too long, OnBeginFrame may flood the task runner with tasks and not allow postMessages to pass. This makes sure that RAFs are executed in the same task queue as postMessages. We also change BeginFrameProvider logic to only disable setNeedsBeginFrame with one frame delay, to minimize the number of mojo calls. Bug: 863962 Cq-Include-Trybots: luci.chromium.try:linux_layout_tests_slimming_paint_v2;master.tryserver.blink:linux_trusty_blink_rel Change-Id: Iec4b21d9e41571a9fc2d9880aa26ce45704d8d0c Reviewed-on: https://chromium-review.googlesource.com/1139188 Commit-Queue: Fernando Serboncini <fserb@chromium.org> Reviewed-by: Chris Harrelson <chrishtr@chromium.org> Reviewed-by: Alexander Timin <altimin@chromium.org> Reviewed-by: Ken Rockot <rockot@chromium.org> Reviewed-by: Justin Novosad <junov@chromium.org> Cr-Commit-Position: refs/heads/master@{#577308} [modify] https://crrev.com/ed98e25e2e6128cb6df6b3eb630b0572d2ef495f/third_party/blink/public/platform/task_type.h [modify] https://crrev.com/ed98e25e2e6128cb6df6b3eb630b0572d2ef495f/third_party/blink/renderer/core/workers/parent_execution_context_task_runners.cc [modify] https://crrev.com/ed98e25e2e6128cb6df6b3eb630b0572d2ef495f/third_party/blink/renderer/core/workers/worker_animation_frame_provider.cc [modify] https://crrev.com/ed98e25e2e6128cb6df6b3eb630b0572d2ef495f/third_party/blink/renderer/core/workers/worker_animation_frame_provider.h [modify] https://crrev.com/ed98e25e2e6128cb6df6b3eb630b0572d2ef495f/third_party/blink/renderer/platform/graphics/begin_frame_provider.cc [modify] https://crrev.com/ed98e25e2e6128cb6df6b3eb630b0572d2ef495f/third_party/blink/renderer/platform/scheduler/main_thread/frame_scheduler_impl.cc [modify] https://crrev.com/ed98e25e2e6128cb6df6b3eb630b0572d2ef495f/third_party/blink/renderer/platform/scheduler/main_thread/main_thread_scheduler_impl.cc [modify] https://crrev.com/ed98e25e2e6128cb6df6b3eb630b0572d2ef495f/third_party/blink/renderer/platform/scheduler/worker/worker_scheduler.cc
,
Jul 23
,
Jul 23
Assigning back to fserb@ since this is addressed by the landed CL which will probably be merged. I've filed a separate bug 866708 to track the ongoing Mojo change.
,
Jul 24
Just noticed that in Canary if you resize the browser window with the worker test running, it freezes. Not 100% sure this is a Chrome bug but filed issue 866855 for that.
,
Jul 24
Able to reproduce the issue on Win-10 using chrome reported version #69.0.3493.0 Tested the fix on Win-10 using latest chrome version #70.0.3501.0 as per the comment #0. Observed that input events did not remain responsive when the FPS is low due to high load in rendering work and the events got slow down. This still seems to be an issue. fserb@ - Could you please check the attached screen cast and please help us in confirming the fix. Thanks...!!
,
Jul 24
krajshree, your demo is WAI. When things drop down to 9FPS, you will get slow updates. The original bug would completely stop sending events.
,
Jul 24
ash, this issue is unrelated. I'll move forwarding merging this.
,
Jul 24
Requesting branch merge. The change is relatively simple (although it touches a few files). We simply post a task. The whole code path is for a feature being launched on M69, so there's no danger of breaking anything else. This bug, on the other hand, is a deal breaker for people using the new feature.
,
Jul 24
M69 Beta promotion is coming VERY soon. Your bug is labelled as Beta ReleaseBlock, pls make sure to land the fix and request a merge into the release branch latest by 1:00 PM PT this Friday, 07/27. Thank you.
,
Jul 25
Your change meets the bar and is auto-approved for M69. Please go ahead and merge the CL to branch 3497 manually. Please contact milestone owner if you have questions. Owners: amineer@(Android), kariahda@(iOS), cindyb@(ChromeOS), govind@(Desktop) For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Jul 25
Pls merge your change to M69 branch 3497 latest by 3:00 PM PT today, Wednesday (07/25/18). Thank you.
,
Jul 25
Merged to 3497.
,
Jul 25
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/8879cbb01887bdb5dfc975f2d760cc6d8a5e63c5 commit 8879cbb01887bdb5dfc975f2d760cc6d8a5e63c5 Author: Fernando Serboncini <fserb@chromium.org> Date: Wed Jul 25 18:16:00 2018 Only execute Worker.RAF inside PostMessage taskrunner If a RAF takes too long, OnBeginFrame may flood the task runner with tasks and not allow postMessages to pass. This makes sure that RAFs are executed in the same task queue as postMessages. We also change BeginFrameProvider logic to only disable setNeedsBeginFrame with one frame delay, to minimize the number of mojo calls. TBR=fserb@chromium.org (cherry picked from commit ed98e25e2e6128cb6df6b3eb630b0572d2ef495f) Bug: 863962 Cq-Include-Trybots: luci.chromium.try:linux_layout_tests_slimming_paint_v2;master.tryserver.blink:linux_trusty_blink_rel Change-Id: Iec4b21d9e41571a9fc2d9880aa26ce45704d8d0c Reviewed-on: https://chromium-review.googlesource.com/1139188 Commit-Queue: Fernando Serboncini <fserb@chromium.org> Reviewed-by: Chris Harrelson <chrishtr@chromium.org> Reviewed-by: Alexander Timin <altimin@chromium.org> Reviewed-by: Ken Rockot <rockot@chromium.org> Reviewed-by: Justin Novosad <junov@chromium.org> Cr-Original-Commit-Position: refs/heads/master@{#577308} Reviewed-on: https://chromium-review.googlesource.com/1150447 Reviewed-by: Fernando Serboncini <fserb@chromium.org> Cr-Commit-Position: refs/branch-heads/3497@{#79} Cr-Branched-From: 271eaf50594eb818c9295dc78d364aea18c82ea8-refs/heads/master@{#576753} [modify] https://crrev.com/8879cbb01887bdb5dfc975f2d760cc6d8a5e63c5/third_party/blink/public/platform/task_type.h [modify] https://crrev.com/8879cbb01887bdb5dfc975f2d760cc6d8a5e63c5/third_party/blink/renderer/core/workers/parent_execution_context_task_runners.cc [modify] https://crrev.com/8879cbb01887bdb5dfc975f2d760cc6d8a5e63c5/third_party/blink/renderer/core/workers/worker_animation_frame_provider.cc [modify] https://crrev.com/8879cbb01887bdb5dfc975f2d760cc6d8a5e63c5/third_party/blink/renderer/core/workers/worker_animation_frame_provider.h [modify] https://crrev.com/8879cbb01887bdb5dfc975f2d760cc6d8a5e63c5/third_party/blink/renderer/platform/graphics/begin_frame_provider.cc [modify] https://crrev.com/8879cbb01887bdb5dfc975f2d760cc6d8a5e63c5/third_party/blink/renderer/platform/scheduler/main_thread/frame_scheduler_impl.cc [modify] https://crrev.com/8879cbb01887bdb5dfc975f2d760cc6d8a5e63c5/third_party/blink/renderer/platform/scheduler/main_thread/main_thread_scheduler_impl.cc [modify] https://crrev.com/8879cbb01887bdb5dfc975f2d760cc6d8a5e63c5/third_party/blink/renderer/platform/scheduler/worker/worker_scheduler.cc
,
Jul 25
,
Jul 26
Is there anything pending here for M69? If not, pls mark bug as fixed.
,
Jul 26
M69 Beta promotion is coming VERY soon. Your bug is labelled as Beta ReleaseBlock, pls make sure to land the fix and request a merge into the release branch latest by 1:00 PM PT this Friday, 07/27. Thank you.
,
Jul 27
,
Jul 27
Marking as fixed per chat with fserb@.
,
Aug 1
Able to reproduce the issue on win-10 using chrome reported version #69.0.3493.0 Verified the fix on Win-10 using Chrome version #69.0.3497.23 as per the comment #0. Attaching screen cast for reference. Observed that input events remain responsive even while the FPS is low due to high load in rendering work. Hence, the fix is working as expected. Adding the verified labels. Thanks...!!
|
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by a...@scirra.com
, Jul 16