Define step timing function for the cc animation framework.

cc/animation/timing_function.cc

Index: cc/animation/timing_function.cc
diff --git a/cc/animation/timing_function.cc b/cc/animation/timing_function.cc
index 2531cc69f36457ccac33f807ad39ce960002f147..8ab8d40eeeccea6841fe77108e95730ce390d4fd 100644
--- a/cc/animation/timing_function.cc
+++ b/cc/animation/timing_function.cc
@@ -5,6 +5,7 @@
 #include "base/logging.h"
 #include "base/memory/scoped_ptr.h"
 #include "cc/animation/timing_function.h"
+#include "cc/base/math_util.h"
 
 namespace cc {
 
@@ -63,4 +64,38 @@ scoped_ptr<TimingFunction> EaseInOutTimingFunction::Create() {
   return CubicBezierTimingFunction::Create(0.42, 0.0, 0.58, 1);
 }
 
+scoped_ptr<StepsTimingFunction> StepsTimingFunction::Create(
+    int steps,
+    float steps_start_offset) {
+  return make_scoped_ptr(new StepsTimingFunction(steps, steps_start_offset));
+}
+
+StepsTimingFunction::StepsTimingFunction(int steps, float steps_start_offset)
+    : steps_(steps), steps_start_offset_(steps_start_offset) {
+  // Restrict it to css presets: step_start, step_end and step_middle.
+  DCHECK(steps_start_offset_ == 0 || steps_start_offset_ == 1 ||
+         steps_start_offset_ == 0.5);

[ajuma, 2014/12/17 16:32:56]

If we're restricting to these values, let's use the StepAtPosition enum instead
of a float as the second argument.

To plumb the enum from Blink to cc, you'll need a version of the enum in Blink
in public/platform (e.g. in WebCompositorAnimationCurve.h) and you'll need to
convert from the Blink enum to the cc enum in cc/blink (e.g. by adding a
conversion function to web_animation_curve_common.{h, cc}).

[loyso (OOO), 2014/12/18 01:53:05]

My initial implementation was absolutely like that. However, after a
conversation with dstockwell@ we decided to go with a float instead of adding
two more enums.

In general, we want to get rid of redundancy (a timing function must be
implemented twice on both sides, for example). Enums is a good demonstration for
the cc_blink pain we have.

Would be nice to have a separate discussion on this topic. Just want to note:
this CL is a short-term change before a massive refactoring.

[ajuma, 2014/12/18 02:15:41]

Ok.

+}
+
+StepsTimingFunction::~StepsTimingFunction() {
+}
+
+float StepsTimingFunction::GetValue(double t) const {
+  return MathUtil::ClampToRange(
+      floor((steps_ * t) + steps_start_offset_) / steps_, 0.0, 1.0);

[ajuma, 2014/12/17 16:32:56]

static_cast<double>(steps_) (rather than having an implicit conversion)

[loyso (OOO), 2014/12/18 01:53:05]

There is a bunch of implicit conversions. steps_ is an integer and return type
is float.
Should I make all of them explicit? Is it mentioned in our style guides?

[ajuma, 2014/12/18 02:15:41]

Yes, please make them explicit. The style guide talks about casts/conversions
here: http://google-styleguide.googlecode.com/svn/trunk/cppguide.html#Casting

[loyso (OOO), 2014/12/18 03:17:30]

That link says nothing on implicit vs. explicit conversions. On the contrary,
that expression is a subject for usual arithmetic conversions (via double in
this case) and it reads well without C++-nasty-style explicit casts. Any other
arguments? :)

[ajuma, 2014/12/18 14:32:54]

It's a (relatively) common practice in cc. It makes clear that a conversion is
happening, without having to lookup the types of the variables involved.

+}
+
+scoped_ptr<TimingFunction> StepsTimingFunction::Clone() const {
+  return make_scoped_ptr(new StepsTimingFunction(*this));
+}
+
+void StepsTimingFunction::Range(float* min, float* max) const {
+  *min = 0.0f;
+  *max = 1.0f;
+}
+
+float StepsTimingFunction::Velocity(double x) const {
+  return 0.0f;
+}
+
 }  // namespace cc