# Re: [csswg-drafts] [css-easing-2] Complex easing/timing functions (#229)

• From: VisibleCode via GitHub <sysbot+gh@w3.org>
• Date: Tue, 30 Apr 2019 18:02:35 +0000
• Message-ID: <issue_comment.created-488053707-1556647354-sysbot+gh@w3.org>
```@AmeliaBR wrote:

> If we adopt a system where you can directly use SVG path notation, then yes, I would expect some sort of reasonable error handling like that.

Fair!

> But if we adopt something like the cubic spline syntax, the main question is can a tool like Greensock implement an algorithm to convert (with a reasonable degree of fidelity) their fixed-up path into the standard notation.

Yes.

@flackr wrote:

> We ended up approximating this inverse scale with a generated linear animation with lots of keyframes but it could have been expressed as a single formula. Could supplying a formula solve some of these other express-ability use cases as well?

Mostly no. (Though having `calc()` available as an _option_ for easing functions is kind of tempting anyhow.) The problem is many functions don't **have** a (practical) formula representation -- _including functions that result from `cubic-bezier()`'s (ab)use of Béziers!_

The simplest general-purpose solution for representing arbitrary functions (including ones that can't be expressed as formulas) is to use a piecewise polynomial approximation.

Piecewise linear (degree 1) is one version of that, but as you discovered needs a lot of keyframes.

Piecewise cubic (degree 3), which we're discussing here, is kind of a sweet spot where you don't need that many extra keyframes, but it's still cheap to evaluate and can't go uncontrollably wiggly as can be a problem for degree >= 4.

--
GitHub Notification of comment by visiblecode
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/229#issuecomment-488053707 using your GitHub account
```

Received on Tuesday, 30 April 2019 18:02:38 UTC