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

cc/trees/layer_tree_host_impl.cc

Index: cc/trees/layer_tree_host_impl.cc
diff --git a/cc/trees/layer_tree_host_impl.cc b/cc/trees/layer_tree_host_impl.cc
index 8a603fae1c2a3f4b3ee3e65c311883c8f1091ad4..cef55fbbad8be43baab9cf2fae81079481de28a9 100644
--- a/cc/trees/layer_tree_host_impl.cc
+++ b/cc/trees/layer_tree_host_impl.cc
@@ -282,6 +282,7 @@ void LayerTreeHostImpl::BeginMainFrameAborted(CommitEarlyOutReason reason) {
   if (CommitEarlyOutHandledCommit(reason)) {
     active_tree_->ApplySentScrollAndScaleDeltasFromAbortedCommit();
     active_tree_->ResetContentsTexturesPurged();
+    RecordMainFrameTiming();

[mithro-old, 2015/03/20 02:17:54]

The fact that this method is being called in two places makes me think it is in
the wrong place.

[vmpstr, 2015/03/20 18:47:26]

Whether this is done in the scheduler or in lthi, I'm not sure where a single
place is that would capture both of these cases:

1. We aborted a commit due to no changes in the trees and properties
2. We processed the commit, rasterized the sync tree, and activated it.

Please let me know if you had a better place in mind.

[mithro-old, 2015/03/23 00:15:08]

If we aborted the commit, should we be generating a frame time value anyway? We
effectively didn't actually generate a main frame or call raf.
I was pondering the NotifyReadyToCommit / BeginMainFrameAborted methods   in the
scheduler for main frame times and the OnBeginImplFrameDeadline for composite
frame times.

[vmpstr, 2015/03/23 20:26:43]

This happens after apply scroll deltas, animate layers, layout, etc. I think
it's just a bit of a misnomer to call this an abort, since we did everything we
would normally do short of creating a pending tree and later activating it. That
is, we successfully finished the frame and we know that we don't have to do
extra work. I'm counting that as a frame that happened... What do you think?

[mithro-old, 2015/03/24 07:37:42]

Despite having worked in this area for a while, I'm always feel like I don't
really understand what is going on most of the time :/

Taking a step back and looking at the specification;

 * PerformanceRenderTiming captures the work performed by the renderer to
process the frame: DOM modification, JavaScript execution, CSS calculation, and
similar activities.

 * PerformanceCompositeTiming captures events performed by the compositor to
place rendered content onto the screen.

I think this maps the following;

 * Create a PerformanceRenderTiming any time we generate new "content" which
maps to any work as part of the "BeginMainFrame" to get stuff ready for the impl
thread including the commit and activate stages.

 * Create a PerformanceCompositeTiming any time we are going to put something
onto the screen (IE Draw and Swap) which maps to any work as part of the
BeginImplFrameDeadline.

Which is why I'm pondering this could be cleaner up at the scheduling level.

On 2015/03/23 20:26:43, vmpstr wrote:
To be exact in your case only the CommitEarlyOutReason::FINISHED_NO_UPDATES
reason matters (which is the only one CommitEarlyOutHandledCommit returns true
on).

Looking at that pathway in ThreadProxy::BeginMainFrame there is the following
comment;
    // Although the commit is internally aborted, this is because it has been
    // detected to be a no-op.  From the perspective of an embedder, this commit
    // went through, and input should no longer be throttled, etc.

But you are correct that this happens *after* all the stuff you mentioned. From
what I can tell, by "no-op" it actually means "there were no evicted UI
resources".

The code also does a "BreakSwapPromises" however looking at the scheduler, there
doesn't appear to be an explicit guarantee for or against a Draw happening after
an aborted commit. 
Yeah, there are lots of things here which could be better named. Makes it even
more important to get new things named correctly so things trend in the right
direction.

   }
 }
 
@@ -1865,6 +1866,7 @@ void LayerTreeHostImpl::ActivateSyncTree() {
         pending_page_scale_animation->scale,
         pending_page_scale_animation->duration);
   }
+  RecordMainFrameTiming();
 }
 
 void LayerTreeHostImpl::SetVisible(bool visible) {
@@ -2106,6 +2108,24 @@ void LayerTreeHostImpl::CreateResourceAndTileTaskWorkerPool(
                                      settings_.renderer_settings.refresh_rate));
 }
 
+void LayerTreeHostImpl::SetCurrentRequestAnimationFrameTime(
+    base::TimeTicks frame_time) {
+  request_animation_frame_time_ = frame_time;
+}
+
+void LayerTreeHostImpl::RecordMainFrameTiming() {
+  std::vector<int64_t> request_ids;
+  active_tree_->GatherFrameTimingRequestIds(&request_ids);
+  if (request_ids.empty())
+    return;
+
+  base::TimeTicks end_time =
+      client_->GetNextPredictedRequestAnimationFrameTime();
+  frame_timing_tracker_->SaveMainFrameTimeStamps(
+      request_ids, request_animation_frame_time_, end_time,
+      active_tree_->source_frame_number());
+}
+
 void LayerTreeHostImpl::DestroyTileManager() {
   tile_manager_ = nullptr;
   resource_pool_ = nullptr;