> In DelegatedFrameHost's resize behavior today, we reject CompositorFrames of 
> the wrong (old) size during a resize, and immediately send back a
> DidReceiveCompositorFrameAck to reduce latency for generating a new
> CompositorFrame. We can probably generalize this behavior with surface
> synchronization.

Just wanna point out that when we time out the lock, the UI makes a frame with gutters, and we allow the next single renderer frame thru with a wrong size.

Ohh interesting. Thanks for pointing that out Dana! I'm going to experiment with implementing this tomorrow to see the impact it has on resize performance and guttering.

I've experimented with this yesterday. Surprisingly, we don't skip frames all that often. If we have an animated page and a bit of main thread jank, then sure we'll skip frames. Random side note: video inside a page while resizing makes me sad, we skip tons of frames...I can't wait until video lives in a Surface...

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

commit 3ca7863c41560e94efdfdb21f0b1b4231e4a589e
Author: fsamuel <fsamuel@chromium.org>
Date: Thu May 04 21:48:53 2017

cc: Only add surface ID to embedded_surfaces if fallback does not match

A child surface ID is either a dependency (something the parents wants
to block its CompositorFrame on and may not exist in the display
compositor yet) or a reference (it is known to exist in the display
compositor).

Dependencies are held in CompositorFrameMetadata::embedded_surfaces, and
references are held in CompositorFrameMetadata::referenced_surfaces.

It was possible for a surface ID to end up in both places if the
primary and fallback SurfaceInfos in a SurfaceLayer matched. This
causes issues in an upcoming CL https://codereview.chromium.org/2831213004/
that "closes" an old fallback surface to receiving new CompositorFrames
if a new primary surface is being requested by a parent to reduce latency.

BUG= 672962 ,  711948 
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_trusty_blink_rel

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

[modify] https://crrev.com/3ca7863c41560e94efdfdb21f0b1b4231e4a589e/cc/layers/surface_layer_impl.cc
[modify] https://crrev.com/3ca7863c41560e94efdfdb21f0b1b4231e4a589e/cc/layers/surface_layer_impl.h
[modify] https://crrev.com/3ca7863c41560e94efdfdb21f0b1b4231e4a589e/cc/layers/surface_layer_impl_unittest.cc

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

commit 980c8ee750096770976476654d13b5ecf412bee4
Author: fsamuel <fsamuel@chromium.org>
Date: Fri May 05 23:28:56 2017

cc: Reject CompositorFrames to old child surfaces

Currently, if a parent is blocked on a child SurfaceID that does not
yet have an active CompositorFrame, the child may continue to submit
CompositorFrames to the old SurfaceID. This eats up CPU cycles that
could be better spent letting the child catch up to the parent's
synchronization request.

With this CL, when a parent submits a CompositorFrame that is blocked
on unresolved dependencies, then existing referenced surfaces with
corresponding dependencies (of the same FrameSinkId) will be "closed",
preventing further CompositorFrames from being submitted to them.
Instead, resources will be immediately returned to the client, and a
DidReceiveCompositorFrameAck will be immediately issued. This reduces
the latency for a child client to catch up to the parent's request.

BUG= 672962 ,  711948 
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_trusty_blink_rel

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

[modify] https://crrev.com/980c8ee750096770976476654d13b5ecf412bee4/cc/output/compositor_frame.cc
[modify] https://crrev.com/980c8ee750096770976476654d13b5ecf412bee4/cc/output/compositor_frame_metadata.h
[modify] https://crrev.com/980c8ee750096770976476654d13b5ecf412bee4/cc/surfaces/compositor_frame_sink_support_unittest.cc
[modify] https://crrev.com/980c8ee750096770976476654d13b5ecf412bee4/cc/surfaces/surface.cc
[modify] https://crrev.com/980c8ee750096770976476654d13b5ecf412bee4/cc/surfaces/surface.h
[modify] https://crrev.com/980c8ee750096770976476654d13b5ecf412bee4/cc/surfaces/surface_factory.cc
[modify] https://crrev.com/980c8ee750096770976476654d13b5ecf412bee4/cc/surfaces/surface_factory.h