iOS Safari used to have a lot of hacks like this to the idle the main thread when gestures were active.  I understand they're starting to do less of that lately.  It's a tradeoff since it adds a lot of semi-arbitrary scheduling complexity and means that useful page content tends to hold off loading for a long time, which can harm usability in its own way.  I can imagine this harming an infinite scroll scenario, for example.

Personally I think we should focus on the passive event listener intervention, and fixing actual unnecessary work (like your other issue http://crbug.com/600203) over this kind of thing.  In the absence of blocking touch events, this work happens asynchronously from the scroll so there's no strong reason to delay it.  And it needs to happen eventually, so there's no overall efficiency improvement from a change like this.

Where you see semi-arbitrary scheduling complexity, I see the opportunity for the scheduler to be smarter about maintaining responsiveness. There are definitely constraints to be considered, but at least intuitively, I don't seem to draw the same conclusions around relative priorities of this work. Maybe something for an in-person conversation to explore this in depth?

The infinite scroll example is a good one for a thought experiment, btw.

I'd be happy to talk further about it.  I do like the idea of aggressive idling of the main thread *conditional on* the presence of a blocking touch listener (which will still be out there even if we intervene, so still worth doing), I'm just skeptical of doing it in general.

The scheduler should probably be using the presence (and/or ongoing interaction with) of a blocking listener as a strong signal.

Just to echo my other comment here, the scheduler already has a policy along these lines but it's only enabled for 10%. It can be forced on like this:

$ build/android/adb_chrome_public_command_line --enable-features=SchedulerExpensiveTaskBlocking

The policy only activates for compositor driven gestures. Earlier we tried to use it for main thread gestures (e.g., touchmove handlers) too, but that proved to be too disruptive for some use cases.

\o/

Yes Sami has a ton of experience with this sort of intervention.  As he found out, it's all too easy to break legitimate use cases (eg. a CAD-like application which does server-rendering as your drag an object around, or even a remote-desktop-like application).

To go further down this path in the spirit of http://bit.ly/user-agent-intervention I think we need some new explicit APIs to help developers indicate their intent - eg. some way to say that a network request is actually critical for interactivity. 

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

commit bb4be51059b55cd04c329d2d296ebcc7e808b215
Author: alexclarke <alexclarke@chromium.org>
Date: Tue May 10 12:16:40 2016

Allow expensive task blocking if there is pending iframe navigation

The motivation for this patch is to gain the benefits of the expensive
task blocking intervention even if an iframe is navigating.  This
should help improve touch responsiveness on ad heavy pages.

We still prevent expensive task blocking when there is a pending main
frame navigation.

BUG=600202

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

[modify] https://crrev.com/bb4be51059b55cd04c329d2d296ebcc7e808b215/components/scheduler/child/web_scheduler_impl.h
[modify] https://crrev.com/bb4be51059b55cd04c329d2d296ebcc7e808b215/components/scheduler/renderer/renderer_scheduler.h
[modify] https://crrev.com/bb4be51059b55cd04c329d2d296ebcc7e808b215/components/scheduler/renderer/renderer_scheduler_impl.cc
[modify] https://crrev.com/bb4be51059b55cd04c329d2d296ebcc7e808b215/components/scheduler/renderer/renderer_scheduler_impl.h
[modify] https://crrev.com/bb4be51059b55cd04c329d2d296ebcc7e808b215/components/scheduler/renderer/renderer_scheduler_impl_unittest.cc
[modify] https://crrev.com/bb4be51059b55cd04c329d2d296ebcc7e808b215/components/scheduler/renderer/renderer_web_scheduler_impl.cc
[modify] https://crrev.com/bb4be51059b55cd04c329d2d296ebcc7e808b215/components/scheduler/renderer/renderer_web_scheduler_impl.h
[modify] https://crrev.com/bb4be51059b55cd04c329d2d296ebcc7e808b215/content/test/fake_renderer_scheduler.cc
[modify] https://crrev.com/bb4be51059b55cd04c329d2d296ebcc7e808b215/content/test/fake_renderer_scheduler.h
[modify] https://crrev.com/bb4be51059b55cd04c329d2d296ebcc7e808b215/third_party/WebKit/Source/core/loader/NavigationScheduler.cpp
[modify] https://crrev.com/bb4be51059b55cd04c329d2d296ebcc7e808b215/third_party/WebKit/Source/core/loader/NavigationScheduler.h
[modify] https://crrev.com/bb4be51059b55cd04c329d2d296ebcc7e808b215/third_party/WebKit/Source/platform/TimerTest.cpp
[modify] https://crrev.com/bb4be51059b55cd04c329d2d296ebcc7e808b215/third_party/WebKit/Source/platform/testing/TestingPlatformSupport.h
[modify] https://crrev.com/bb4be51059b55cd04c329d2d296ebcc7e808b215/third_party/WebKit/public/platform/WebScheduler.h

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

commit 82a129abeafa1bd8184b5c3e61ab2c7568edd3f8
Author: alexclarke <alexclarke@chromium.org>
Date: Tue May 10 15:28:50 2016

Throttling Helper to disable task queue until PumpThrottledTasks called

This patch fixes a bug that caused some loading & timer tasks to run
when we expected them to be blocked.  In SYNCHRONIZED_GESTURE use case
we use the ThrottlingHelper to allow these tasks to run once per second.
Unfortunately the design of the ThrottlingHelper did not consider tasks
that where in a TaskQueue's work queues.  It marked the queues as being
manually pumped which prevented reloading of the work queues.

For the case of background tab throttling where the throttle state
changes very infrequently, that works acceptably.  In the context of
task blocking, its totally broken and the queues might as well not have
been throttled at all.

This patch fixes that by initially disabling any queues that are
throttled.  The queues are re-enabled by PumpThrottledTasks() and also
if the queue is unthrottled.

BUG=600202

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

[modify] https://crrev.com/82a129abeafa1bd8184b5c3e61ab2c7568edd3f8/components/scheduler/renderer/renderer_scheduler_impl.cc
[modify] https://crrev.com/82a129abeafa1bd8184b5c3e61ab2c7568edd3f8/components/scheduler/renderer/renderer_scheduler_impl_unittest.cc
[modify] https://crrev.com/82a129abeafa1bd8184b5c3e61ab2c7568edd3f8/components/scheduler/renderer/throttling_helper.cc
[modify] https://crrev.com/82a129abeafa1bd8184b5c3e61ab2c7568edd3f8/components/scheduler/renderer/throttling_helper_unittest.cc

Alex's patch above already improved cnn.com pretty visibly. Attached is a trace of one more problem we're hitting: somehow the scheduler is fooled into thinking we're main thread scrolling at 1477ms even though the touch handler didn't preventDefault(), causing task blocking to get disabled.

Deleted: chrome-profile-results-2016-05-11-141727.html 15.1 MB

chrome-profile-results-2016-05-11-141727.html 15.1 MB Download

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

commit 1fd38c63f6df73d7d9d86f312b02a1c0d4b08d78
Author: skyostil <skyostil@chromium.org>
Date: Wed May 11 19:23:27 2016

scheduler: Detect when a main thread touch stream turns into a compositor gesture

When a main thread gesture turns into a compositor driven gesture (e.g.,
because the touch handler didn't preventDefault(), allowing the
compositor to scroll), we previously failed to update the detected use
case from MAIN_THREAD_GESTURE to COMPOSITOR_GESTURE. This patch makes
sure we always update our policy whenever the use case detected from the
input stream hanges, ensuring an appropriate scheduling policy is
activated.

BUG=600202

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

[modify] https://crrev.com/1fd38c63f6df73d7d9d86f312b02a1c0d4b08d78/components/scheduler/renderer/renderer_scheduler_impl.cc
[modify] https://crrev.com/1fd38c63f6df73d7d9d86f312b02a1c0d4b08d78/components/scheduler/renderer/renderer_scheduler_impl.h
[modify] https://crrev.com/1fd38c63f6df73d7d9d86f312b02a1c0d4b08d78/components/scheduler/renderer/renderer_scheduler_impl_unittest.cc

Caveat emptor to anyone trying this: task blocking is still behind a 10% finch experiment, so unless you're very lucky you might need to use --enable-features=SchedulerExpensiveTaskBlocking to turn it on. We're debating whether to expand the experiment.

The current policy seems to be doing a pretty good job on cnn.com right now. There's still a 1 second long task it can't reliably deal with, because there really isn't a good time to run a task like that. I think we'll practically need something like the passive event listener intervention to manage these cases.

I'm extending the finch trial for this feature to get some data from the updated policy (cl/122422866).

Deleted: chrome-profile-results-2016-05-13-182107.html 13.3 MB

chrome-profile-results-2016-05-13-182107.html 13.3 MB View Download

The trial is showing the median delay from passive event listeners (i.e., ones that didn't ultimately block scrolling) dropping from 50ms to 30ms (internal link: go/qhyxo). There's also a similar trend in the overall touch-to-first-scroll-update latency of a reduction in the number of delays above ~50ms. I think the policy is working.

I'll still see how AMP is doing but I think we can turn the current policy on by default.

Here's a trace from AMP. The good news is that it's running pretty decently (Nexus 6P, [obama] query). The bad news is that during user gestures the scheduler is firmly in the MAIN_THREAD_CUSTOM_INPUT_HANDLING policy. This basically means that there is a Javascript touch handler driving the animation, and the scheduler can't reliably work out which tasks are important for it to function. Therefore we try to prioritize all tasks equally and avoid blocking anything.

In the past we've tried blocking loading tasks in this state, but that ended up breaking some sites (e.g., a remote desktop type application which streamed new graphics frames from the server in response to touch events).

I think the options here are:

1. Come up with some heuristic to determine if loading tasks are necessary for an active user gesture. I don't have concrete ideas yet -- maybe we could distinguish between XHRs and other types of loading.

2. Concede defeat and switch AMP to compositor worker.

Deleted: chrome-profile-results-2016-06-01-102218.html 15.2 MB

chrome-profile-results-2016-06-01-102218.html 15.2 MB Download

Thank you so much for working on this, Sami and Alex.

I agree, the CompositorWorker is the way to go for this type of effect in the future content.

Here's hoping that we can improve the situation on the scheduler side for the existing content (AMP carousel being a stand-in representative for that content).

I've been looking at the latest trace, and it looks like most of the super-sized slices  during is_gesture_active are the ParseHTML tasks. I wonder if it is possible to block the tasks posted by HTMLParserThread while is_guesture_active without causing too many fires?

That seems worth trying at least. I've been thinking of adding some "QoS" classes for loading tasks. Besides these kinds of "deferrable" or "low priority" tasks, there's been a request for a high priority network queue for cheap network tasks related to prefetching.

Leaving unassigned for now.

This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available. If you change it back, also remove the "Hotlist-Recharge-Cold" label.

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

There's some renewed interest in doing this now that we're moving a part of the renderer scheduling logic into the browser.