CC: Allow cubic-bezier timing inputs outside the range [0, 1]

ui/gfx/geometry/cubic_bezier_unittest.cc

Index: ui/gfx/geometry/cubic_bezier_unittest.cc
diff --git a/ui/gfx/geometry/cubic_bezier_unittest.cc b/ui/gfx/geometry/cubic_bezier_unittest.cc
index 168817c6449ec9caf4f02705092b9080e3904fbe..31496a898cc6982e27a5233ed28aaff50285de00 100644
--- a/ui/gfx/geometry/cubic_bezier_unittest.cc
+++ b/ui/gfx/geometry/cubic_bezier_unittest.cc
@@ -164,5 +164,23 @@ TEST(CubicBezierTest, Slope) {
   EXPECT_NEAR(function.Slope(1), 0, epsilon);
 }
 
+TEST(CubicBezierTest, InputOutOfRange) {
+  CubicBezier simple(0.5, 1.0, 0.5, 1.0);
+  EXPECT_EQ(-2.0, simple.Solve(-1.0));
+  EXPECT_EQ(1.0, simple.Solve(2.0));
+
+  CubicBezier coincidentEndpoints(0.0, 0.0, 1.0, 1.0);
+  EXPECT_EQ(-1.0, coincidentEndpoints.Solve(-1.0));
+  EXPECT_EQ(2.0, coincidentEndpoints.Solve(2.0));

[Ian Vollick, 2015/01/05 15:36:04]

It'd be nice to have a test where one of the endpoints was coincident, but the
other wasn't. Also, having the first three knots coincident would be interesting
(0.0, 0.0, 0.0, 0.0).

[loyso (OOO), 2015/01/06 02:24:53]

As I mentioned above, this is a port of tests from here:
https://codereview.chromium.org/238573002

I agree, we should add this test. But to be consistent, we should add it on both
sides (cc/blink). I could setup a bug and introduce it as a separate CL.
What's the priority for that?

+
+  CubicBezier verticalGradient(0.0, 1.0, 1.0, 0.0);
+  EXPECT_EQ(0.0, verticalGradient.Solve(-1.0));
+  EXPECT_EQ(1.0, verticalGradient.Solve(2.0));
+
+  CubicBezier distinctEndpoints(0.1, 0.2, 0.8, 0.8);
+  EXPECT_EQ(-2.0, distinctEndpoints.Solve(-1.0));
+  EXPECT_EQ(2.0, distinctEndpoints.Solve(2.0));
+}
+
 }  // namespace
 }  // namespace gfx