Timer floods + clicking buttons seems to hang the renderer on Android |
|||
Issue descriptionChrome Version: 58.0.3029.124 (Official Build) (32-bit) OS: Android What steps will reproduce the problem? (1) Go to https://people-mozilla.org/~bkelly/timer-flood/index.html (2) Click Start (3) Wait about 10 seconds and click Stop (4) Use a pinch gesture to zoom What is the expected result? The zoom should happen What happens instead? The page freezes at (3) and the zoom gesture is ignored. Sometimes it recovers eventually, other times the render displays an oops. Issue 703608 is related in that that slows the animation in the page, but fixing that issue does not solve the hang on tapping Stop. This issue also only seems to happen on Android.
,
May 25 2017
It seems I was missing some steps out to repro there. New repro steps: (1) and (2) the same. (3) Use pinch gesture to zoom (4) Repeatedly pan until the page stops updating (5) Tap the Stop button The problem is really at (4), where the renderer_scheduler_impl enters UseCase::COMPOSITOR_GESTURE which in this case sets the compositor_queue priority to best effort. Because of the timer flood, this means the normal priority timer queue runs continuously and compositor_queue gets stuck. The UseCase can never switch away from COMPOSITOR_GESTURE because there are pending events in the UserModel which can't be serviced because the compositor queue never runs. So we have a couple of options to try: 1) Add a new priority between NORMAL and BEST_EFFORT which always runs tasks but less often than NORMAL. 2) Add a safety valve that raises the compositor task queue priority when pending events are waiting but are never serviced.
,
May 31 2017
,
May 31 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/bd8aaee01b0dcf66a19f52ec97d63700a8b4c66a commit bd8aaee01b0dcf66a19f52ec97d63700a8b4c66a Author: Dan Elphick <delphick@chromium.org> Date: Wed May 31 17:04:41 2017 Prevent compositor queue starvation. Create a new TaskQueue priority LOW_PRIORITY which runs less frequently than NORMAL but unlike BEST_EFFORT, is guaranteed to run. When in UseCase::COMPOSITOR_GESTURE, set the compositor TaskQueue to LOW_PRIORITY rather than BEST_EFFORT. When choosing whether to unblock a previously starved queue, use a score rather task count now that we have different priorities to unblock. Bug: 725850 Change-Id: I08af91032d658e80ed5ef0956d4ad826a84c1635 Reviewed-on: https://chromium-review.googlesource.com/515542 Commit-Queue: Dan Elphick <delphick@chromium.org> Reviewed-by: Sami Kyöstilä <skyostil@chromium.org> Cr-Commit-Position: refs/heads/master@{#475950} [modify] https://crrev.com/bd8aaee01b0dcf66a19f52ec97d63700a8b4c66a/third_party/WebKit/Source/platform/scheduler/base/task_queue.h [modify] https://crrev.com/bd8aaee01b0dcf66a19f52ec97d63700a8b4c66a/third_party/WebKit/Source/platform/scheduler/base/task_queue_impl.cc [modify] https://crrev.com/bd8aaee01b0dcf66a19f52ec97d63700a8b4c66a/third_party/WebKit/Source/platform/scheduler/base/task_queue_selector.cc [modify] https://crrev.com/bd8aaee01b0dcf66a19f52ec97d63700a8b4c66a/third_party/WebKit/Source/platform/scheduler/base/task_queue_selector.h [modify] https://crrev.com/bd8aaee01b0dcf66a19f52ec97d63700a8b4c66a/third_party/WebKit/Source/platform/scheduler/base/task_queue_selector_unittest.cc [modify] https://crrev.com/bd8aaee01b0dcf66a19f52ec97d63700a8b4c66a/third_party/WebKit/Source/platform/scheduler/renderer/renderer_scheduler_impl.cc [modify] https://crrev.com/bd8aaee01b0dcf66a19f52ec97d63700a8b4c66a/third_party/WebKit/Source/platform/scheduler/renderer/renderer_scheduler_impl_unittest.cc
,
Jun 1 2017
|
|||
►
Sign in to add a comment |
|||
Comment 1 by skyos...@chromium.org
, May 24 2017