Is this a problem outside of resizing that client?

Set Available/Feature on this type of tracking issue so we don't have to go through them in our triage.

To Dana's question: this is primarily a resize concern but I'm trying to design/build surface sync to be a generic best-effort multi-client synchronization system. As a hypothetical example, suppose we wish to evict out-of-process iframes that are out of view. If we then scroll them back into view, and the OOPIF is slow, then we'll jank (kinda sucky). Now, so suppose you scroll away (the OOPIF gets evicted because we are under memory pressure or something) and scroll back. 

Surface sync now knows that this client has missed a deadline recently, and may miss again so we don't block the parent on the child this time.

This is more serious for interactive resize though.

If the system recognizes that the renderer is hopelessly slow (because slashdot.org is just plain slow :() [I'm a slashdot fan, don't judge...], then surface sync stops blocking browser UI on SurfaceIDs from the slow renderer until its starts behaving again (generating a frame within the provided deadline).

This means more guttering of the render and less guttering of browser UI which is generally good if web content is hopelessly slow.

+gklassen@ since we chatted about surface sync briefly yesterday.

> then surface sync stops blocking browser UI on SurfaceIDs from the slow renderer until its starts behaving again

This reads like you'd start resizing the browser at 60 fps, which will take away a lot of resources from the renderer trying to make a frame. The current system will generate one frame when the lock times out, then grab the lock again.

#5: That's a very good point. We probably don't want to spam the renderer with resize requests to the point where it keeps falling further and further behind...

What I was trying to capture in this bug is on some web pages, resize is just very slow, and trying to synchronize will cause jank without necessarily reducing guttering.

Maybe this doesn't matter once we throttle input to BeginFrames and CompositorFrame activation: https://bugs.chromium.org/p/chromium/issues/detail?id=712454

If the client is slow, the client's content is very important to user and user is thirst for it, skip this slow content is not so friendly.

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

commit 4717fddfddb2640549abf1a6d689ac6f9c2bca96
Author: Fady Samuel <fsamuel@chromium.org>
Date: Sat Jan 27 04:36:57 2018

Surface synchronization: Reset deadline to 0 after one-shot.

A deadline should never be set more than once for a CompositorFrame
unless a client explicitly requests a second shot. This CL resets
the deadline in frames to 0 on a SurfaceLayer after commit and after
activation from pending to active layer trees. If the client expliclty
requests a new deadline, then another shot will be taken. base::nullopt
signifies to use whatever default deadline the viz service decides.

Bug: 707510,  672962 
Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.android:android_optional_gpu_tests_rel
Change-Id: I856c74a2c50f287d1085b4b99330c42ba6bbeb64
Reviewed-on: https://chromium-review.googlesource.com/887743
Commit-Queue: Fady Samuel <fsamuel@chromium.org>
Reviewed-by: Saman Sami <samans@chromium.org>
Cr-Commit-Position: refs/heads/master@{#532156}
[modify] https://crrev.com/4717fddfddb2640549abf1a6d689ac6f9c2bca96/cc/layers/surface_layer.cc
[modify] https://crrev.com/4717fddfddb2640549abf1a6d689ac6f9c2bca96/cc/layers/surface_layer_impl.cc
[modify] https://crrev.com/4717fddfddb2640549abf1a6d689ac6f9c2bca96/cc/layers/surface_layer_impl_unittest.cc
[modify] https://crrev.com/4717fddfddb2640549abf1a6d689ac6f9c2bca96/cc/layers/surface_layer_unittest.cc
[modify] https://crrev.com/4717fddfddb2640549abf1a6d689ac6f9c2bca96/cc/trees/layer_tree_host_impl_unittest.cc
[modify] https://crrev.com/4717fddfddb2640549abf1a6d689ac6f9c2bca96/components/viz/service/surfaces/surface.cc
[modify] https://crrev.com/4717fddfddb2640549abf1a6d689ac6f9c2bca96/components/viz/service/surfaces/surface.h