Add new latency_info for tracking browser composite time.

content/browser/renderer_host/render_widget_host_impl.cc

Index: content/browser/renderer_host/render_widget_host_impl.cc
diff --git a/content/browser/renderer_host/render_widget_host_impl.cc b/content/browser/renderer_host/render_widget_host_impl.cc
index 2c57a2b78d543dafaff3170cf9d2447cc2ce5d62..099c1f8adccedef3c0e58d236c059badd2ce1c10 100644
--- a/content/browser/renderer_host/render_widget_host_impl.cc
+++ b/content/browser/renderer_host/render_widget_host_impl.cc
@@ -89,6 +89,10 @@ namespace {
 
 bool g_check_for_pending_resize_ack = true;
 
+const size_t kBrowserCompositeLatencyHistorySize = 60;
+const double kBrowserCompositeLatencyEstimationPercentile = 90.0;
+const double kBrowserCompositeLatencyEstimationSlack = 1.1;
+
 typedef std::pair<int32, int32> RenderWidgetHostID;
 typedef base::hash_map<RenderWidgetHostID, RenderWidgetHostImpl*>
     RoutingIDWidgetMap;
@@ -186,7 +190,8 @@ RenderWidgetHostImpl::RenderWidgetHostImpl(RenderWidgetHostDelegate* delegate,
       has_touch_handler_(false),
       weak_factory_(this),
       last_input_number_(static_cast<int64>(GetProcess()->GetID()) << 32),
-      next_browser_snapshot_id_(1) {
+      next_browser_snapshot_id_(1),
+      browser_composite_latency_history_(kBrowserCompositeLatencyHistorySize) {
   CHECK(delegate_);
   if (routing_id_ == MSG_ROUTING_NONE) {
     routing_id_ = process_->GetNextRoutingID();
@@ -1451,6 +1456,13 @@ bool RenderWidgetHostImpl::OnSwapCompositorFrame(
   input_router_->OnViewUpdated(
       GetInputRouterViewFlagsFromCompositorFrameMetadata(frame->metadata));
 
+  for (size_t i = 0; i < frame->metadata.latency_info.size(); ++i) {
+    frame->metadata.latency_info[i].AddLatencyNumber(
+        ui::INPUT_EVENT_RENDERER_SWAP_RECEIVED_COMPONENT,
+        GetLatencyComponentId(),
+        0);
+  }
+
   if (view_) {
     view_->OnSwapCompositorFrame(output_surface_id, frame.Pass());
     view_->DidReceiveRendererFrame();
@@ -2142,6 +2154,21 @@ void RenderWidgetHostImpl::FrameSwapped(const ui::LatencyInfo& latency_info) {
           100);
     }
   }
+
+  ui::LatencyInfo::LatencyComponent gpu_swap_component;
+  if (!latency_info.FindLatency(
+          ui::INPUT_EVENT_GPU_SWAP_BUFFER_COMPONENT, 0, &gpu_swap_component)) {
+    return;
+  }
+
+  ui::LatencyInfo::LatencyComponent composite_component;
+  if (latency_info.FindLatency(ui::INPUT_EVENT_RENDERER_SWAP_RECEIVED_COMPONENT,

[no sievers, 2014/10/01 22:15:08]

Hmm, so does that ignore the time it took the renderer to composite and for the
SwapCompositorFrame msg to make it from renderer to UI thread?

[orglofch, 2014/10/02 00:46:04]

Yea this is just for the browser composite time. We're using it to inform the
renderer of how much time it has until the next swap, so we don't need to take
into account renderer composite time or SwapCompositorFrame propagation time
since the deadline refers to the swap on the gpu service.

[no sievers, 2014/10/02 20:17:42]

Ah ok, it looks like the renderer adjusts the deadline by how long it takes to
child-composite:
begin_impl_frame_args_.deadline -= draw_duration_estimate;

Maybe the slack needs to be a bit bigger to also account for the latency between
sending the frame, running OnSwapCompositorFrame, and actually running
Composite(). On Android we often have high latency from these IPC thread hops. 

+                               GetLatencyComponentId(),
+                               &composite_component)) {
+    base::TimeDelta delta =
+        gpu_swap_component.event_time - composite_component.event_time;
+    browser_composite_latency_history_.InsertSample(delta);
+  }
 }
 
 void RenderWidgetHostImpl::DidReceiveRendererFrame() {
@@ -2260,7 +2287,8 @@ void RenderWidgetHostImpl::CompositorFrameDrawn(
       if (b->first.first == ui::INPUT_EVENT_LATENCY_BEGIN_RWH_COMPONENT ||
           b->first.first == ui::WINDOW_SNAPSHOT_FRAME_NUMBER_COMPONENT ||
           b->first.first == ui::WINDOW_OLD_SNAPSHOT_FRAME_NUMBER_COMPONENT ||
-          b->first.first == ui::TAB_SHOW_COMPONENT) {
+          b->first.first == ui::TAB_SHOW_COMPONENT ||
+          b->first.first == ui::INPUT_EVENT_RENDERER_SWAP_RECEIVED_COMPONENT) {
         // Matches with GetLatencyComponentId
         int routing_id = b->first.second & 0xffffffff;
         int process_id = (b->first.second >> 32) & 0xffffffff;
@@ -2315,6 +2343,18 @@ BrowserAccessibilityManager*
       delegate_->GetOrCreateRootBrowserAccessibilityManager() : NULL;
 }
 
+base::TimeDelta RenderWidgetHostImpl::GetEstimatedBrowserCompositeTime() {
+  if (browser_composite_latency_history_.SampleCount() > 0) {
+
+    return browser_composite_latency_history_.Percentile(
+               kBrowserCompositeLatencyEstimationPercentile) *
+        kBrowserCompositeLatencyEstimationSlack;

[no sievers, 2014/10/01 22:15:08]

Can we also use the stddev or variance when coming up with the slack?

[orglofch, 2014/10/02 00:46:04]

We could, however, we run the risk of a one-off really bad frame messing with
our slack estimates causing sort-of cascading bad estimates (which is also why
we use the 90th percentile when selecting our estimate instead of the worst
case). Let me know if this is overly cautious. 

[no sievers, 2014/10/02 20:17:42]

I was actually more worried that we end up using something that is too close and
then end up missing vsync every 10th frame or so. Wouldn't that cause jank?

Is there another way we can come up with a number min_composite_time here and
use the smaller of min_composite_time and the percentile here?
Even if that value is just the hardcoded value we currently use (1/3 of
vsync_period or whatever it is).

I thought we are mostly trying to fix the problem of devices where our current
constant is too small (those devices take longer to do all the work across the
threads).

What I don't understand is what the gain is from moving the deadline closer to
the next vsync for devices that are actually faster.

Or also: what is the problem with using an immediate deadline for devices that
are slower and having main thread commits run in higher latency?

[orglofch, 2014/10/02 22:17:56]

Per our offline discussion, I've used the original estimate as the lower bound
to prevent potential regressions in the short time on slow devices. 

Will followup on cases where the min_estimate is too large and we want to give
the impl thread more time to activate etc. separately.

+  } else {
+    return base::TimeDelta::FromMicroseconds(
+        (1.0f * base::Time::kMicrosecondsPerSecond) / (3.0f * 60));
+  }
+}
+
 #if defined(OS_WIN)
 gfx::NativeViewAccessible
     RenderWidgetHostImpl::GetParentNativeViewAccessible() {