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

I do like @visiblecode's proposal for hand-authoring friendliness (especially with an automatic curve fitting option), and for the fact that it directly defines y as a function of x, so doesn't need arbitrary limits or fix-ups.

But hand-authoring is only half of the argument. The other is compatibility with existing tools.

> Also worth adding that segments of cubic splines are easy to convert into Bernstein form, so implementors can re-use code they already have around for evaluating Béziers.

Do you have a link to the relevant formulae?  Are these exact conversions or approximations?

Ideally, this would become the new "master" syntax, that could represent all the keyword and function-notation easings [defined in the current spec](https://drafts.csswg.org/css-easing/).  In particular, I'd be interested to know if your definition of "automatic" velocity calculations matched [Blender's automatic handles](https://docs.blender.org/manual/en/latest/editors/graph_editor/fcurves/introduction.html).

But we'd also want to directly represent curves that can be generated in popular animation software, like AfterEffects and Blender, which seem to use a mix of straight lines and cubic curves (with internally-enforced limits on the curves to keep them always increasing in the x direction). 

We'd also want to make it possible to convert from software that currently uses path notation, like Greensock. Which, [based on my testing with their visualizer](https://greensock.com/ease-visualizer), seems to use the rule proposed by @SebastianZ to convert arbitrary paths into functions.


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

Received on Tuesday, 30 April 2019 01:58:36 UTC