Refactoring the way begin frame sources inside scheduler work.

cc/output/begin_frame_args.h

Index: cc/output/begin_frame_args.h
diff --git a/cc/output/begin_frame_args.h b/cc/output/begin_frame_args.h
index 025a4075c25e6b84ab9597dabac7e5c83b34ea1b..1aa38e29b169b9dbb22c6486d74ee1527d8fcdeb 100644
--- a/cc/output/begin_frame_args.h
+++ b/cc/output/begin_frame_args.h
@@ -6,6 +6,7 @@
 #define CC_OUTPUT_BEGIN_FRAME_ARGS_H_
 
 #include "base/time/time.h"
+#include "base/values.h"
 #include "cc/base/cc_export.h"
 
 namespace cc {
@@ -39,6 +40,15 @@ struct CC_EXPORT BeginFrameArgs {
 
   bool IsValid() const { return interval >= base::TimeDelta(); }
 
+  scoped_ptr<base::Value> AsValue() const {
+    scoped_ptr<base::DictionaryValue> state(new base::DictionaryValue);
+    state->SetString("type", "BeginFrameArgs");

[brianderson, 2014/05/07 17:20:16]

I don't think we use this "type" pattern anywhere else. Would it be more
flexible to have the caller clarify it if needed?

[mithro-old, 2014/05/07 22:02:32]

I'd really like to have a type field because then in telemetry we can then find
"all dictionaries of type BeginFrameArgs" easily.

Should this be moved into it's own change? This function (with a little bit of
extra code) can be used to make it possible to use BeginFrameArgs in
TRACE_EVENTs...

[brianderson, 2014/05/08 00:55:58]

Please split it out to a separate patch, yes. If you feel strongly about keeping
the type, I won't push it - I see value too in being able to search for such an
important type in traces.

[mithro-old, 2014/05/09 02:45:58]

Done.

+    state->SetInteger("frame_time_us", frame_time.ToInternalValue());
+    state->SetInteger("deadline_us", deadline.ToInternalValue());
+    state->SetInteger("interval_us", interval.InMicroseconds());
+    return state.PassAs<base::Value>();
+  }
+
   base::TimeTicks frame_time;
   base::TimeTicks deadline;
   base::TimeDelta interval;