Add Set Authoritative VSync Interval function

Add Set Authoritative VSync Interval function

This add functionality to set "authoritative" Vsync interval to
scheduler. This interval would come from display configuration, which is
more reliable than 3D context. Pull the SetAuthoritativeVSyncInterval
from CL 775143003.

R=brianderson@chromium.org
BUG=372086

[weiliangc, 2014-12-11 20:30:18]

This is pretty independent so I pulled it out of CL 775143003.

[simonhong, 2014-12-11 23:09:46]

simonhong@chromium.org changed reviewers:
+ simonhong@chromium.org

[simonhong, 2014-12-11 23:09:46]

LGTM

https://codereview.chromium.org/791373003/diff/1/cc/scheduler/scheduler.cc
File cc/scheduler/scheduler.cc (right):

https://codereview.chromium.org/791373003/diff/1/cc/scheduler/scheduler.cc#ne...
cc/scheduler/scheduler.cc:456: void
Scheduler::SetAuthoritativeVSyncInterval(base::TimeDelta interval) {
nit: How about add DCHECK(settings_.forward_begin_frame_source); ?

SetAuthoritativeVSyncInterval() will only be called on that mode.

[brianderson, 2014-12-12 01:11:39]

TLDR:
1) STP needs to implement CommitVSyncParameters like TP does.
2) I don't think we need to land this patch before unified begin frame if we do
1, but landing this ahead of time wouldn't hurt.
3) Compositor::SetAuthoritativeVSyncInterval needs to be hooked up if we are
going to land this.
4)  We can delete CompositorVSyncManager after unified begin frame lands to
simplify the unified begin frame review.

====

Looks like the Compositor needs to be notified of the authoritative interval
from the DisplayController in this patch.

https://code.google.com/p/chromium/codesearch#chromium/src/ash/display/displa...

We can't remove the old code path until unified begin frame lands though. At
that point, we can delete CompositorVSyncManager.

I'm realizing this patch isn't actually a pre-requisite for unified begin frame
since the Browser cc::Scheduler should already get the authoritative vsync
indirectly via CommitVSyncParameters.

STP currently has an empty implementation for CommitVSyncParameters though,
which should be implemented as part of the STP SchedulerClient work.

https://codereview.chromium.org/791373003/diff/1/cc/trees/thread_proxy.cc
File cc/trees/thread_proxy.cc (right):

https://codereview.chromium.org/791373003/diff/1/cc/trees/thread_proxy.cc#new...
cc/trees/thread_proxy.cc:1255: NOTREACHED() << "Only used by SingleThreadProxy";
I think this will be true after CrOS is STP. If you want to land it before then
you'll need to forward it to the impl thread.

[mithro-old, 2015-02-27 02:26:03]

mithro@mithis.com changed reviewers:
+ mithro@mithis.com

[mithro-old, 2015-03-11 04:24:49]

Looking at this patch, I think almost all of it should go away as
UnifiedBeginFrame lands. I'm unsure the usefulness of landing it only to remove
a month later.

[simonhong, 2015-03-11 05:17:02]

On 2015/03/11 04:24:49, mithro wrote:
> Looking at this patch, I think almost all of it should go away as
> UnifiedBeginFrame lands. I'm unsure the usefulness of landing it only to
remove
> a month later.

Current authoritative impl will be removed in the second landing step of unified
BeginFrame.
Please refer to https://codereview.chromium.org/775143003/.