cc: Use BeginFrameArgs

cc/output/begin_frame_args.cc

Index: cc/output/begin_frame_args.cc
diff --git a/cc/output/begin_frame_args.cc b/cc/output/begin_frame_args.cc
index cefb22bdc1382aa20f6217a5f077fad39d5daa98..cef1526beca1b3cab91d039255fae48dedebfe98 100644
--- a/cc/output/begin_frame_args.cc
+++ b/cc/output/begin_frame_args.cc
@@ -49,9 +49,7 @@ BeginFrameArgs BeginFrameArgs::CreateExpiredForTesting() {
 }
 
 base::TimeDelta BeginFrameArgs::DefaultDeadlineAdjustment() {
-  // Using a large deadline adjustment will effectively revert BeginFrame
-  // scheduling to the hard vsync scheduling we used to have.
-  return base::TimeDelta::FromSeconds(-1);
+  return base::TimeDelta::FromMicroseconds(-16666/3);
 }
 
 base::TimeDelta BeginFrameArgs::DefaultInterval() {
@@ -63,4 +61,13 @@ base::TimeDelta BeginFrameArgs::DefaultRetroactiveBeginFramePeriod() {
 }
 
 
+void BeginFrameArgs::AdjustDeadline(base::TimeDelta delta) {
+#if defined(OS_ANDROID)
+  deadline += delta;
+#else
+  deadline = base::TimeTicks();

[brianderson, 2013/08/08 02:45:05]

@piman: I know you had reservations previously about using a hard-coded deadline
on ChromeOS, but after playing around with a hard coded deadline localy, I don't
see many negatives of using a deadline - even if it's not very accurate. If we
make the deadlines, we get awesome latency. If we don't, then the scheduler
falls back to the old behavior.

The only negative I can think of is that, in theory, sometimes we might start in
a low latency mode and jank to a higher latency mode. In that case, it may have
been better to target a higher latency in the first place.  In practice though,
I find that fast pages are fast and slow pages are janky anyway.

Do you mind if I remove this ifdef?

+#endif
+}
+
+
 }  // namespace cc