scheduler: Optimize for TouchStart responsiveness by modeling what the user is doing.
We have come to realize that TouchStart responsiveness is really critical for a
good user experience. This patch introduces a (initially very simple) system
for modeling what the user is doing and predicting when they are likely to
initiate a new gesture (taps are ignored). We order task priority accordingly.
In addition we extend the estimation of task cost to loading tasks
which are often a significant source of jank.
Load tasks can be very long (easily up to 1000ms). There is
no good way to cooperatively schedule such a task but the
least worst user experience seems to be if we get them out
of the way as fast as possible. Ideally we'd prioritize them
but the order of IPC and LoadingTasks currently needs to
be more or less in lockstep. Instead we deprioritize compositor
tasks inside a compositor gesture, which has the effect of
prioritizing other work.
Expected changes on Perf bots:
1. first_gesture_scroll_update_latency in smoothness.scrolling_tough_ad_cases
should go down. This should be highly user visible.
2. It's possible some compositor metrics such as queueing_durations
may regress. I don't expect this to be user visible.
This is a reland of https://codereview.chromium.org/
1320633002.
Original author: Alex Clarke <alexclarke@chromium.org>
BUG=510398,530250
CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel
TBR=jochen@chromium.org
Review URL: https://codereview.chromium.org/
1340073003
Cr-Commit-Position: refs/heads/master@{#348886}