Rework UI CompositorResizeLock interaction with DelegatedFrameHost
This removes the CanLockCompositorState enum, and replaces it with
2 bools, in order to disconnect the resize lock from the renderer.
The old code was built on the assumption that renderer frames will
cause a commit in the UI but this is no longer the case as they go
directly to the display compositor (which is now separate from the
UI compositor). Now the bools track things for the UI compositor.
The first bool |create_resize_lock_after_commit_| allows us to get
rid of the resize lock if it times out. While this bool is true we
do not remake a resize lock in the meantime, and once the UI makes
a single frame and commits, we can re-lock the UI compositor as we
make a new resize lock. The second bool is the only interaction of
the resize lock with the renderer, allowing a renderer frame to be
submitted once the lock has timed out, since we're allowing one UI
frame through also, so that a slow renderer (causing timeout) will
not remain at its original size indefinitely. This 2nd bool's name
is |allow_one_renderer_frame_during_resize_lock_|. These changes I
made also mean that we no longer entertain the concept of deferred
resize locks. This was used to allow the UI to make a frame before
locking the compositor. Now we just always hold/release the resize
lock directly, along with |create_resize_lock_after_commit_| state
to prevent relocking the UI before producing a frame after unlock.
R=piman@chromium.org
BUG=704928
Review-Url: https://codereview.chromium.org/2790623003
Cr-Commit-Position: refs/heads/master@{#461734}
11 files changed
