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

cc/scheduler/scheduler.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/scheduler/scheduler.h"
 
 #include <algorithm>
 
 #include "base/auto_reset.h"
 #include "base/logging.h"
@@ skipping 281 matching lines @@
       begin_impl_frame_args_.interval <= base::TimeDelta())
     return base::TimeTicks();
 
   base::TimeTicks now = Now();
   base::TimeTicks timebase = std::max(begin_impl_frame_args_.frame_time,
                                       begin_impl_frame_args_.deadline);
   int64 intervals = 1 + ((now - timebase) / begin_impl_frame_args_.interval);
   return timebase + (begin_impl_frame_args_.interval * intervals);
 }
 
-base::TimeTicks Scheduler::LastBeginImplFrameTime() {
+base::TimeTicks Scheduler::LastBeginImplFrameTime() const {
   return begin_impl_frame_args_.frame_time;
 }
 
+base::TimeTicks Scheduler::NextBeginImplFrameTimeIfRequested() const {

[mithro-old, 2015/03/11 04:01:32]

Why do you need this method? 

[vmpstr, 2015/03/16 18:36:43]

This returns the next predicted raf time which is one of the values I need to
report. I've changed the name to hopefully better reflect the intent.

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

Can you link me to why you need this? I was pretty sure the spec didn't require
it..

Using frame_time + interval as the "next frame time" is also fundamentally
broken when not using vsync throttling.

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

The spec I'm working off is here:
http://w3c.github.io/frame-timing/#performancerendertiming

In particular,

"The end of the frame is defined as what the beginning time of the next frame's
requestAnimationFrame callback (see [Animation-Timing]) would have been, had one
been scheduled in the current frame. If a requestAnimationFrame is already
requested, its beginning time should be used."

The last sentence is a recent change that isn't a part of this patch though.

What time is the appropriate one to use in this situation? That is, if there is
no raf scheduled and this frame is over, we need to know that the next raf time
would have been if it was scheduled.

My understanding from talking to brianderson@ that you have a patch that would
ensure that the impl frame time is always updated at the right time. Since (also
from my possibly flawed understanding), this is the frame args that would also
be used for the main frame time, it would make a good candidate for predicting
what the next raf would be. Please let me know if this is not the case. Also, if
it isn't the case, what do you think is the right time to use here?

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

Reading the spec, my understanding is that you should be using the actual frame
time of the next frame, this means waiting until that frame is generated rather
than trying to predict the value.

The "had one been scheduled in the current frame" means the scheduler will need
to receive one more BeginFrameArgs after SetNeedsBeginFrame has become false to
get the ending time - which as brianderson points out we already do. I don't
think this information gets down to the LTHI however.

+  return begin_impl_frame_args_.frame_time + begin_impl_frame_args_.interval;
+}
+
 void Scheduler::SetupNextBeginFrameIfNeeded() {
   if (!task_runner_.get())
     return;
 
   if (state_machine_.ShouldSetNeedsBeginFrames(
           frame_source_->NeedsBeginFrames())) {
     frame_source_->SetNeedsBeginFrames(state_machine_.BeginFrameNeeded());
     if (!frame_source_->NeedsBeginFrames()) {
       client_->SendBeginMainFrameNotExpectedSoon();
     }
@@ skipping 554 matching lines @@
 }
 
 bool Scheduler::IsBeginMainFrameSentOrStarted() const {
   return (state_machine_.commit_state() ==
               SchedulerStateMachine::COMMIT_STATE_BEGIN_MAIN_FRAME_SENT ||
           state_machine_.commit_state() ==
               SchedulerStateMachine::COMMIT_STATE_BEGIN_MAIN_FRAME_STARTED);
 }
 
 }  // namespace cc