Add new latency_info for tracking browser composite time.

content/browser/renderer_host/render_widget_host_impl.cc

 // Copyright (c) 2012 The Chromium Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
 #include "content/browser/renderer_host/render_widget_host_impl.h"
 
 #include <math.h>
 #include <set>
 #include <utility>
 
@@ skipping 71 matching lines @@
 using blink::WebKeyboardEvent;
 using blink::WebMouseEvent;
 using blink::WebMouseWheelEvent;
 using blink::WebTextDirection;
 
 namespace content {
 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;
 base::LazyInstance<RoutingIDWidgetMap> g_routing_id_widget_map =
     LAZY_INSTANCE_INITIALIZER;
 
 int GetInputRouterViewFlagsFromCompositorFrameMetadata(
     const cc::CompositorFrameMetadata metadata) {
   int view_flags = InputRouter::VIEW_FLAGS_NONE;
 
@@ skipping 77 matching lines @@
       input_method_active_(false),
       text_direction_updated_(false),
       text_direction_(blink::WebTextDirectionLeftToRight),
       text_direction_canceled_(false),
       suppress_next_char_events_(false),
       pending_mouse_lock_request_(false),
       allow_privileged_mouse_lock_(false),
       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();
     surface_id_ = GpuSurfaceTracker::Get()->AddSurfaceForRenderer(
         process_->GetID(),
         routing_id_);
   } else {
     // TODO(piman): This is a O(N) lookup, where we could forward the
     // information from the RenderWidgetHelper. The problem is that doing so
     // currently leaks outside of content all the way to chrome classes, and
@@ skipping 1244 matching lines @@
   param.b.AssignTo(frame.get());
   std::vector<IPC::Message> messages_to_deliver_with_frame;
   messages_to_deliver_with_frame.swap(param.c);
 
   for (size_t i = 0; i < frame->metadata.latency_info.size(); i++)
     AddLatencyInfoComponentIds(&frame->metadata.latency_info[i]);
 
   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();
   } else {
     cc::CompositorFrameAck ack;
     if (frame->gl_frame_data) {
       ack.gl_frame_data = frame->gl_frame_data.Pass();
       ack.gl_frame_data->sync_point = 0;
     } else if (frame->delegated_frame_data) {
       cc::TransferableResource::ReturnResources(
@@ skipping 671 matching lines @@
         swap_component.event_time - original_component.event_time;
     for (size_t i = 0; i < original_component.event_count; i++) {
       UMA_HISTOGRAM_CUSTOM_COUNTS(
           "Event.Latency.TouchToScrollUpdateSwap",
           delta.InMicroseconds(),
           1,
           1000000,
           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() {
   view_->DidReceiveRendererFrame();
 }
 
 void RenderWidgetHostImpl::WindowSnapshotAsyncCallback(
     int routing_id,
     int snapshot_id,
     gfx::Size snapshot_size,
@@ skipping 98 matching lines @@
     const std::vector<ui::LatencyInfo>& latency_info) {
   for (size_t i = 0; i < latency_info.size(); i++) {
     std::set<RenderWidgetHostImpl*> rwhi_set;
     for (ui::LatencyInfo::LatencyMap::const_iterator b =
              latency_info[i].latency_components.begin();
          b != latency_info[i].latency_components.end();
          ++b) {
       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;
         RenderWidgetHost* rwh =
             RenderWidgetHost::FromID(process_id, routing_id);
         if (!rwh) {
           continue;
         }
         RenderWidgetHostImpl* rwhi = RenderWidgetHostImpl::From(rwh);
         if (rwhi_set.insert(rwhi).second)
@@ skipping 34 matching lines @@
     RenderWidgetHostImpl::GetRootBrowserAccessibilityManager() {
   return delegate_ ? delegate_->GetRootBrowserAccessibilityManager() : NULL;
 }
 
 BrowserAccessibilityManager*
     RenderWidgetHostImpl::GetOrCreateRootBrowserAccessibilityManager() {
   return delegate_ ?
       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() {
   return delegate_ ? delegate_->GetParentNativeViewAccessible() : NULL;
 }
 #endif
 
 SkColorType RenderWidgetHostImpl::PreferredReadbackFormat() {
   if (view_)
     return view_->PreferredReadbackFormat();
   return kN32_SkColorType;
 }
 
 }  // namespace content