cc: Add main frame timing info to frame timing tracker.

cc/trees/thread_proxy.cc

 // Copyright 2011 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 "cc/trees/thread_proxy.h"
 
 #include <algorithm>
 #include <string>
 
 #include "base/auto_reset.h"
@@ skipping 673 matching lines @@
 
   if (!impl().layer_tree_host_impl->settings().impl_side_painting) {
     DCHECK_GT(impl().layer_tree_host_impl->memory_allocation_limit_bytes(), 0u);
   }
   begin_main_frame_state->memory_allocation_limit_bytes =
       impl().layer_tree_host_impl->memory_allocation_limit_bytes();
   begin_main_frame_state->memory_allocation_priority_cutoff =
       impl().layer_tree_host_impl->memory_allocation_priority_cutoff();
   begin_main_frame_state->evicted_ui_resources =
       impl().layer_tree_host_impl->EvictedUIResourcesExist();
+  impl().layer_tree_host_impl->SetBeginMainFrameTime(

[enne (OOO), 2015/03/06 00:00:57]

I'm not quite sure I follow what this is doing.  When you send a begin main
frame message, you record a time.  But, we could have many BeginImplFrames
between the time this BeginMainFrame happens and activation later.  Maybe this
is part of my confusion about what start and end are supposed to represent.

[vmpstr, 2015/03/06 00:59:53]

So this is meant to capture the time it takes for a content update to make it to
screen. Or in general, how long it takes the layout, javascript, whatever else,
rasterization, and activation to run. 

Start time refers to the beginning of the main frame. It's the time we would use
in rAF if rAF was fired. The end time represents the time after all of the above
work has finished. To be a bit more specific, it's the time of rAF that would
happen after we can display new content, if such a rAF was scheduled. So end -
start should be a multiple of 16ms in most cases and it provides a signal that
says "you made the frame" vs "you didn't make the frame". A sequence of 16ms
16ms 32ms 32ms 16ms should represent "good 60fps for the first 2 frames",
followed by "something slow-ish that skipped a frame twice", followed by
"another good frame". 

Does that make sense? This is what I'm trying to capture. The fact that there
are multiple impl frames is ok, as long as we record the main frame once on
commit and measure it until the next activation. It's entirely possible that
this code isn't correct, but what I described is what I'm trying to accomplish
:)

+      impl().scheduler->LastBeginImplFrameTime());
   Proxy::MainThreadTaskRunner()->PostTask(
       FROM_HERE,
       base::Bind(&ThreadProxy::BeginMainFrame,
                  main_thread_weak_ptr_,
                  base::Passed(&begin_main_frame_state)));
   devtools_instrumentation::DidRequestMainThreadFrame(
       impl().layer_tree_host_id);
   impl().timing_history.DidBeginMainFrame();
 }
 
@@ skipping 684 matching lines @@
   impl().scheduler->DidPrepareTiles();
 }
 
 void ThreadProxy::DidCompletePageScaleAnimationOnImplThread() {
   DCHECK(IsImplThread());
   Proxy::MainThreadTaskRunner()->PostTask(
       FROM_HERE, base::Bind(&ThreadProxy::DidCompletePageScaleAnimation,
                             main_thread_weak_ptr_));
 }
 
+base::TimeTicks ThreadProxy::GetNextBeginImplFrameTimeIfRequested() const {
+  DCHECK(IsImplThread());
+  return impl().scheduler->NextBeginImplFrameTimeIfRequested();
+}
+
 }  // namespace cc