GitLab

Unlike PostTask from IO thread to compositor thread in Chrome IPC, mojo
polls for messages on the compositor thread which means it can dequeue a
large number of begin frame messages after the compositor thread has
been busy for some time. All but the last begin frame cancels the
previous begin frame, and is essentially a nop, but it still ticks
animations. When a page has a large number of animations each begin
frame can take a long time and push out other tasks such as tile manager
callbacks stalling the pipeline.

Throttling the begin frames in viz doesn't fully solve the problem
because we have to allow at least two begin frames in flight for
pipelining, and so the client can still process two begin frames back to
back.

Throttling in AsyncLTFS causes issues with LTFS lifetime and ordering
with respect to other messages.

Saving incoming begin frame in scheduler and posting a task works and
ensures that only one begin frame is outstanding at any time.

R=danakj
BUG=782002

Cq-Include-Trybots: luci.chromium.try:android_optional_gpu_tests_rel;master.tryserver.blink:linux_trusty_blink_rel
Change-Id: I247a87ad7475d33f878a215ce87056d20482f88c
Reviewed-on: https://chromium-review.googlesource.com/1130082
Commit-Queue: Sunny Sachanandani <sunnyps@chromium.org>
Reviewed-by: danakj <danakj@chromium.org>
Cr-Commit-Position: refs/heads/master@{#577046}