commit 1ee6fb5c206f8f63176196bfc31aa40721b734c7
author Fady Samuel <fsamuel@chromium.org> Fri Feb 16 03:27:46 2018
committer Commit Bot <commit-bot@chromium.org> Fri Feb 16 03:27:46 2018
tree 77eaa435f4ce314b981e7833e3e4a4fb3f6297ce
parent 6011b67f7820781c3e097c5c3cacab0926c46a04

Surface synchronization: Throttle auto-resize renderer side

This is a short term fix until child-allocated LocalSurfaceIDs are implemented
for auto-resize.

Prior to surface synchronization, child renderers would allocate LocalSurfaceIds
for auto-resize. When the renderer receives a DidReceiveCompositorFrameAck
message then it knows the compositor has received the frame, and informs the
browser process which then resizes the associated aura window to match the
frame generated by the child. This ensured that the aura window would only be
resized to a size that had a surface.

With surface synchronization, every auto-resize resulted in a request for a
LocalSurfaceId from the parent. The parent would immediately resize the aura
window and embed the newly allocated LocalSurfaceId and then tell the child
about it. In the meantime, the child may auto-resize again. Surface
synchronization would block the parent on that LocalSurfaceId
that never resolves until the child makes another request. After the deadline
passes, the user sees flicker.

This CL does not address the root cause of the problem (allocating IDs for
surfaces that are never created), but it does significantly reduce the problem.

Instead of immediately informing the browser when an auto-resize happens in the
renderer. The ACK is posted as a task on the renderer's queue. The renderer may
auto-resize multiple times until that task is handled, and so we effectively
coalesce resize requests before making a request to the browser.

This significantly reduces flicker.

This is not the final state of auto-resize, though. In the future, the renderer
will immediately allocate a LocalSurfaceId and submit a CompositorFrame, and
then tell the browser about it to embed it. Occasionally, there will be a
conflict between browser and renderer changes, but this should be very rare.

Bug: 812127, 811181, 672962
Change-Id: I08839c4b498b68ba06bb5d818337738e191cf9be
Reviewed-on: https://chromium-review.googlesource.com/920341
Commit-Queue: Fady Samuel <fsamuel@chromium.org>
Reviewed-by: Antoine Labour <piman@chromium.org>
Cr-Commit-Position: refs/heads/master@{#537173}