Using CAMediaTimingFunction to calculate value at time (t)

It's unfortunate, but Core Animation doesn't expose its internal computational model for its animation timing. However, what has worked really well for me is to use Core Animation to do the work!

1. Create a CALayer to serve as an evaluator
2. Set its frame to ((0.0, 0.0), (1.0, 1.0))
3. Set isHidden to true
4. Set speed to 0.0
5. Add this layer to some container layer

6. When you want to evaluate any CAMediaTimingFunction, create a reference animation:

   let basicAnimation = CABasicAnimation(keyPath: "bounds.origin.x")
   basicAnimation.duration = 1.0
   basicAnimation.timingFunction = timingFunction
   basicAnimation.fromValue = 0.0
   basicAnimation.toValue = containerLayer.bounds.width
   
   referenceLayer.add(basicAnimation, forKey: "evaluatorAnimation")
   

7. Set the reference layer's timeOffset to whatever normalized input value (i.e., between 0.0 and 1.0) you want to evaluate:

   referenceLayer.timeOffset = 0.3    // 30% into the animation
   

8. Ask for the reference layer's presentation layer, and get its current bounds origin x value:

   if let presentationLayer = referenceLayer.presentation() as CALayer? {
       let evaluatedValue = presentationLayer.bounds.origin.x / containerLayer.bounds.width
   }
   

Basically, you're using Core Animation to run an animation for an invisible layer. But the layer's speed is 0.0, so it won't progress the animation at all. Using timeOffset, we can manually adjust the current position of the animation then get its presentation layer's x position. This represents the current perceived value of that property as driven by the animation.

It's a little unconventional, but there's nothing hacky about it. It's as faithful a representation of the output value of a CAMediaTimingFunction as you can get because Core Animation is actually using it.

The only thing to be aware of is that presentation layers are close approximations of the values presented on screen. Core Animation makes no guarantees as to their accuracy, but in all my years of using Core Animation, I've never seen it be inaccurate. Still, if your application requires absolute accuracy, it's possible this technique might not be the best.

Note: I am not an expert on CoreAnimation. This is just my understanding from reading the docs you have linked.

Apple is mixing coordinate systems here, which is creating some confusion.

x(t) in the example plots represents a scalar progression along some path, not a physical coordinate.

The control points used in CAMediaTimingFunction are used to describe this progression, not a geometric points. To add to the confusion, x in the control points actually maps to t on the plots and y in the control points to x(t) on the plots.

To take the plot for kCAMediaTimingFunctionEaseInEaseOut as an example, this plot would be described roughly by control points (0,0), (0.5,0), (0.5,1), (1,1).

Best hint would probably be UnitBezier.h in WebKit's source code. In fact, I guess Apple uses the same code inside Core Animation.

More lengthy, they use calculate parameter t (which has nothing to do with time) given a value of x which actually contains the time value. Then they use Newton-Raphson method (additional explanation with examples). Since it can fail, they iterate a bit more to using bisection ("divide and conquer"). See this in solveCurveX() method.

After getting parameter t (which is necessary given that cubic Beziers are parametrically defined), they simply use it to calculate y. See this in solve() method.

By the way, a big fan of Cappuccino, and still hoping for a release of Atlas :-)

---

Update January 2020: I did this back in 2012 in my implementation of the Core Animation APIs. Feel free to refer to it.

CoreAnimation's CAMediaTimingFunction does what you want but doesn't expose getting 'y' for a given 'x' for versatile (animation) use but rather just feeds the solved values opaquely to the animation system under the hood.

I needed it myself so built a class with the interface and capabilities exactly like CAMediaTimingFunction but with the needed -valueForX: method; usage example:

RSTimingFunction *heavyEaseInTimingFunction = [RSTimingFunction timingFunctionWithControlPoint1:CGPointMake(0.8, 0.0) controlPoint2:CGPointMake(1.0, 1.0)];
CGFloat visualProgress = [heavyEaseInTimingFunction valueForX:progress];

You can create ease-in, ease-out, ease-in-ease-out or really any curves that can be described with a cubic Bézier curve. The implementation math is based on WebCore (WebKit), which is presumably what CoreAnimation is using under the hood too.

Enjoy, Raphael