Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[css-easing-2] Complex easing/timing functions #229

Open
rachelnabors opened this issue Jun 24, 2016 · 92 comments
Open

[css-easing-2] Complex easing/timing functions #229

rachelnabors opened this issue Jun 24, 2016 · 92 comments
Assignees
Labels

Comments

@rachelnabors
Copy link

@rachelnabors rachelnabors commented Jun 24, 2016

In light of the Webkit team's implementation of spring(), it's apparent we need to attend to the issue of complex timing functions sooner rather than later.

The problem

Designers often need more advanced timing functions than can be described with cubic-beziers. They are not limited to spring functions, either. A common problem is there is no effective way to export a timing graph from Adobe After Effects to a timing function that could be used with CSS or with the Web Animations API. Currently designers have to hack together individual timing functions using CSS animation keyframes, which is impossible to do by hand in all but the most trifling instances.

spring() is just a bandaid.

The solution

We need a format to write functions like spring() in, one that we can export to from software like AfterEffects and prototyping tools that have yet to be built.

I am not in a position to propose the technical specifications of this solution. But there are people who have that knowledge. I have invited them (@visiblecode) to share their proposals below.

@birtles
Copy link
Contributor

@birtles birtles commented Jun 24, 2016

There is some previous discussion of this topic, thread starting here: https://lists.w3.org/Archives/Public/public-fx/2015JulSep/0034.html

@visiblecode
Copy link

@visiblecode visiblecode commented Jun 24, 2016

Cubic beziers aren't a bad choice for timing functions. They're very easy to evaluate (just a few additions and multiplications). Also, most animation tools use some form of cubic spline to specify animation paths, which can be converted into cubic bezier easings with good fidelity.

There are two problems with cubic-bezier() as it is currently specced, however:

  1. You can't specify a spline of multiple segments
  2. cubic-bezier() is abusing 2d parametric curves to specify 1d functions

The first issue can be addressed by, essentially, just adding more points to the cubic-bezier() syntax. I believe this has already been proposed in various forms.

The second issue is pretty significant, though, and deserves some unpacking. cubic-bezier() is specified as a 2d bezier, a 2d parametric curve. This has a lot of implications, including:

  1. Without additional constraints, the resulting curve isn't guaranteed to have a singular y value for a given x and can't be used to define a mathematical function. This has been dealt with by restricting x to the range [0, 1], but that doesn't actually address the root (no pun) problem -- because a cube root is involved there are still two extra solutions in the complex plane.
  2. As mentioned, implementors must solve cube roots to work backwards from x to the implicit t parameter, before they get to the normal (and much simpler/exact!) bezier calculation to evaluate the easing function.
  3. Tool authors who want to do a direct conversion of cubic spline segments to cubic-bezier()s have no use at all for the extra dimension, but must clutter the output with decimal approximations of 1/3 and 2/3.

The extra dimension isn't useful and makes life harder for implementors and tool authors alike. Ideally, instead of having to specify a two-dimensional curve like cubic-bezier(0.33333, 0.4, 0.66666, 0.6), we ought to have gotten one-dimensional curves, e.g. cubic-bezier(0.4, 0.6).

With one dimension, instead of having to work backwards from (normalized) time to an implicit t, the normalized time could be used directly as the input without having to solve cube roots first.

I guess if I were going to make a concrete proposal, I'd like to see syntax for specifying 1d bezier splines, in a format something like cubic-spline(c, [c,t,c,]* c) (where the cs and ts are numbers).

The first and last values are exactly like the control points in cubic-bezier(), except since we're only dealing with one dimension, the "control points" are specified by scalar values, rather than pairs of them.

Between those end "control values", you could have zero or more (control value, time, control value) triples representing intermediate knots with their adjacent control "points". The knot times (the middle value of the triples) would have to be monotonically increasing, in the range (0, 1).

As a concrete example, let's take the following complex easing:

 @keyframes example {
     from {
         some-property: 100px;
         animation-timing-function: cubic-bezier(0.33333, 0.25, 0.66666, 0.8);
     }
     50% {
         some-property: 75px;
         animation-timing-function: cubic-bezier(0.33333, 0.5, 0.66666, 0.6);
     }
     to {
         some-property: 50px;
     }
 }

Given the aforementioned cubic-spline() function, you could define the same animation more simply as:

 @keyframes example {
     from {
         some-property: 100px;
         animation-timing-function: cubic-spline(0.125, 0.4,0.5,0.75, 0.8);
     }
     to {
         some-property: 50px;
     }
 }

IMO this seems better for both export tooling and hand authoring.

One thing this proposal doesn't address are use cases where you want easings/animations with sudden jumps in them. (i.e. not C0 continuous) Having multiple intermediate CSS keyframes may still be a good answer for animations with discontinuities (rather than trying to define timing functions with discontinuities), though in order to do that there would need to be a mechanism to specify different incoming and outgoing property values for a CSS keyframe.

@visiblecode
Copy link

@visiblecode visiblecode commented Jun 24, 2016

One of the things that bothers me about spring() specifically is that it requires finding an approximate solution to a differential equation, just like cubic-bezier() requires approximate solving of cube roots (only moreso). Browsers' approximations will vary, and there are performance/quality tradeoffs.

Using (1d) bezier splines for defining easing functions is far simpler than something like spring() computationally, and is easy to pull off with good precision. It's also relatively easy for tools to "bake" a physically-based animation (including ones much more complex than spring simulations) into a spline, which animation tools do anyway for better reproduceability and performance.

@visiblecode
Copy link

@visiblecode visiblecode commented Jun 24, 2016

Thinking about it overnight, cubic-polybezier() might be a more accurate/less misleading name than cubic-spline(). I'll let other people bikeshed about naming though.

@visiblecode
Copy link

@visiblecode visiblecode commented Jun 24, 2016

I'm also an idiot; those triples need to be four-tuples, there's an extra position parameter which I left out. So that example/proposal is wrong.

@visiblecode
Copy link

@visiblecode visiblecode commented Jun 24, 2016

Adding the missing position parameter to the two control values, the syntax would be something like cubic-spline(c, [c, t, p, c,]* c). And that example becomes:

@keyframes {
    from {
        some-property: 100px;
        animation-timing-function: cubic-spline(0.125, 0.4, 0.5,0.5, 0.75, 0.8);
    }
    to {
        some-property: 50px;
    }
}
@visiblecode
Copy link

@visiblecode visiblecode commented Jul 1, 2016

Having thought about this for a while and chatted with others, I think the minimum required features for representing complex easing functions boil down to:

Piecewise cubics are pretty much the common denominator for animation software, which either uses some form of piecewise cubic spline directly, or else curves which are reasonably easy to convert to piecewise cubics.

The main exception are animation tools which are doing physical simulations. Even then, some simple physical systems can be directly represented. For example, piecewise cubics are more than enough to precisely represent physically-accurate "bouncing ball" easings, since ballistic trajectories are simple parabolic arcs.

Oscillating spring (or pendulum) easings are sinusoidal and not exactly representable using simple polynomials, but you can still do a good job of approximating them by gluing multiple cubic segments together. If spring() became part of the standard, it might make sense to define it in terms of an appropriate piecewise cubic approximation.

I don't know how often jump continuities are really needed in easing functions, but they're certainly required if you want to be able to define a single easing function to recreate existing complex @keyframes animations which use timing functions like step-start() or step-end(). So it seems worth including them.

@visiblecode
Copy link

@visiblecode visiblecode commented Jul 1, 2016

It's probably worth observing that motion curves (as opposed to timing/easing curves) in animation software are a little bit of a different story. There you're more likely to find NURBS or other more sophisticated types of curves which require a bit more work to approximate with cubic segments.

On the 1d versus 2d issue -- From what I can see so far, After Effects uses one-dimensional piecewise functions for timing curves, although I don't have a copy to play with directly. However, poking at the implementation of Blender, it appears Blender f-curve segments do work similarly to cubic-bezier(), using (suitably constrained) 2d bezier curves to define the 1d function.

@visiblecode
Copy link

@visiblecode visiblecode commented Jul 1, 2016

Additional observation: while you can muddle through with multiple keyframes and cubic-bezier() easings for most purposes, if you need smooth curves joined by a jump discontinuity, @keyframes as currently specified can't be made to work. Best you can currently do to simulate such a jump discontinuity is to define two keyframes very close together and use a step easing between them:

@keyframes example {
    from {
        blah: 10px;
        animation-timing-function: cubic-bezier( ... stuff ... );
    }
    49.99999% {
        blah: 40px;
        animation-timing-function: step-end;
    }
    50% {
        blah: 100px;
        animation-timing-function: cubic-bezier( ... stuff ...);
    }
    to {
        blah: 150px;
    }
}
@birtles
Copy link
Contributor

@birtles birtles commented Jul 1, 2016

Best you can currently do to simulate such a jump discontinuity is to define two keyframes very close together and use a step easing between them

Yes, this is actually quite common to see. The Web Animations API allows you to overlap keyframe offsets so that you can add discontinuities and I believe there has been discussion in the past of adding syntax to allow you to do this in CSS keyframes (e.g. 50%+).

@visiblecode
Copy link

@visiblecode visiblecode commented Jul 1, 2016

One suggestion made in the Slack discussion, which I had promised to document here, was to use an SVG path to specify an easing function.

In that case, any SVG path could be allowed, at least provided it ranged between 0 and 1 in the x dimension, and the curve's x component was continuous and monotonic over that range as well. In that case, the M operator could used to indicate jump discontinuities.

So, for two cubic segments joined by a jump discontinuity 50% of the way through, you might have something like: animation-timing-function: path("M 0,0 C 0.17,0.1, 0.33,0.2 0.5,0.4 M 0.5,0.8 C 0.67,0.8 0.83,0.9, 1,1")

I have mixed feelings about this, but it would work, aside from the issue of needing to indicate whether you wanted left- or right- continuity at any jumps.

@visiblecode
Copy link

@visiblecode visiblecode commented Jul 1, 2016

The idea I had floated prior to that was something like: animation-timing-function: complex-easing(cubic(0, 0.1, 0.2, 0.4), 0.5, cubic(0.8, 0.8, 0.9, 1))

(In spite of cubic() having a superficial resemblance to cubic-bezier(), the parameters are all y values.)

i.e. two one-dimensional cubic bezier segments which meet at x = 0.5, but the first ends at y = 0.4, and the second begins at y = 0.8. Still doesn't address the issue of directional continuity though.

It does also require you to repeat the y/output value even when you want the two segments to join with C0 continuity. For example if the first segment ended at y = 0.4, and the second began there:

animation-timing-function: complex-easing(cubic(0, 0.1, 0.2, 0.4), 0.5, cubic(0.4, 0.8, 0.9, 1))

This also wouldn't allow for a direct translation of blender f-curves, while I think SVG paths would.

@rachelnabors
Copy link
Author

@rachelnabors rachelnabors commented Jul 4, 2016

This also wouldn't allow for a direct translation of blender f-curves, while I think SVG paths would.

That concerns me. Also, I can't imagine how to write a script to export to this format from a motion graph in, say, After Effects.

@visiblecode
Copy link

@visiblecode visiblecode commented Jul 5, 2016

There's a meta issue here in that there's a bit of a mismatch between the way AE deals with animation and CSS to begin with. More specifically, animation-timing-function doesn't directly correspond to motion (v.s. timing) graphs in AE. It's more akin to the time remapping feature.

That being said, if you extract the x, y, etc. components from the motion separately (like the AE "separate dimensions" feature does), then you could turn them into separate animations with timing functions in the format I gave. But then CSS would need to provide a nice way to combine multiple transform: animations. (Today, you have to play tricks with nested divs.)

@birtles
Copy link
Contributor

@birtles birtles commented Jul 6, 2016

But then CSS would need to provide a nice way to combine multiple transform: animations. (Today, you have to play tricks with nested divs.)

We have that in CSS Animations 2: animation-composition

@grorg
Copy link
Contributor

@grorg grorg commented Jul 14, 2016

So if we ignore the composition and what-i-call-triggers-but-might-be-also-called-chaining, and assume spring() is handled separately (#280), and see @rachelnabors's recent tweet, can we start by adding some hardcoded shortcuts?

The majority of those on easings.net are variations of a cubic-bezier. If these are really useful, and if other implementors agree, we can add keywords for them.

Unless I've missed some, the functions on easings.net that are not supported by CSS are:

  • easeInElastic
  • easeOutElastic
  • easeInOutElastic
  • easeInBounce
  • easeOutBounce
  • easeInOutBounce

How popular are these? The first two are very much like spring().

Looking at tools...

After Effects only seems to have a couple of built-ins, which it calls "easy ease". However, it allows you to manually create some pretty complicated curves.

Apple's Motion does things in two different ways. It has "Behaviours" which are animation effects that you don't really see as keyframes and easing (more like "move in this direction with this speed and friction"). For the traditional keyframe animations, it has a manual editing mode like After Effects, but some shortcuts for bezier, linear, exponential, logarithmic and continuous.

Cinema 4D has basic ease in/out/both, linear and steps. It also has some tooling for smoothing keyframes (e.g. smooth tangents) which would likely produce curves that we couldn't exactly match in CSS at the moment.

Can people provide other examples?

@notoriousb1t
Copy link

@notoriousb1t notoriousb1t commented Jul 14, 2016

@visiblecode. While I understand the hesitance to create an easing path function similar to SVG paths, I think it would make easings like GSAP's RoughEase.ease easier to do for tool makers.

http://greensock.com/ease-visualizer and click on Rough

@vidhill
Copy link

@vidhill vidhill commented Jul 18, 2016

Hi,

I know there are two different types of animation being discussed in this, predetermined animation curves and programmatic animations, like Apple's spring.

I've been thinking about the latter and I think I have an idea.

What if we could facilitate scripted animation for transition values.

Here is the proposition I have arrived at..
I think it actually looks similar to how Houdini code will look, but I haven't delved deply into that as yes.

Anyway, your css would look something like this

.my-element {
    /* transition: transform 500ms url('../simple.js'); */
    transition: transform 500ms url('../bounce.js')(1 100 10 0);
    transform: translate(0px, 0px);
}

.my-element.active {
    transform: translate(200px, 200px);
}

Simple example of an ease function file

File: simple.js

/**
 * The simplest possible easing function, linear
 */
export init function(){
    //in this case init does nothing
}

/**
 * Function that gets called every frame until a done() callback / promise.resolve()
 * @param {float} t - Transition current Time, value from 0 to 1
 * @param {Promise} - Promise that gets resolved when animation is complete
 * @return {float} A value 0 is not transitioned at all and 1 is fully transitioned
 */
export frame function(t, animationComplete){
    if(t === 1){
        animationComplete.resolve('done');
    }    
    return t; // linear, very boring..
}

Example of how something more complex, e.g. Apple's bounce transition effect could be defined using this method

File: bounce.js

/**
 * Simulate a spring using the solving algorithm defined by this JavaScript
  function
 * @param {float} The mass of the object attached to the end of the spring. Must be greater
  than 0. Defaults to 1.
 * @param {integer} The spring stiffness coefficient. Must be greater than 0.
  Defaults to 100.
  * @param {integer} The initial velocity of the object attached to the spring.
  Defaults to 0, which represents an unmoving object..
  Defaults to 10.
   * @param {float} initialVelocity  
 */
export init function((mass, stiffness, damping, initialVelocity)){
    // code that need to be run once during initialization
    // -real code 
}

/**
 * Fuction that gets called every frame until a done() callback / promise.resolve()
 * @param {float} t - Time, value from 0 to 1
 * @param {promise} - Promise that gets resolved when animation is complete
 * @return {float} A value from 0 to 1+ where 0 is not transitioned at all and 1 is fully transitioned, in the case of spring the value overshoots 1 initially then eventually settles on 1 
 */
export frame function(t, animationComplete){
    // -real code
    // -real code
    return result;
}

The browser would know up front about the function and could, I assume be prepared,

Different variations of the spring, for example could be achieved by passing different values into the init function, which could be done from the CSS, no need to touch the js.

Obviously some code savvy people could share their functions with the community, and feasibly come up with some very clever stuff. And it would not need to go through the standards process, in the spirit of the Houdini project

The frame function would at maximum be executed every frame,
But of course the browser could decide to drop/skip frames if it needed,

The browser itself could work out how much rounding would happen.
The only thing the script could do is return a value 0-1 obviously overshooting 1 if the ease necessitated

@rachelnabors
Copy link
Author

@rachelnabors rachelnabors commented Jul 19, 2016

Interesting perspective, @vidhill. Thanks for sharing. I am personally a bit hesitant to wait to see how Houdini's adoption goes and what hiccups will come down the line when we could nail down a spec today. But if we can't, you very well may have described the future.

@grorg Thanks for joining the conversation! I'd love to see browsers offer more defaults than just ease-in, linear, etc. I was thinking adding easeOutQuint and the like. That's probably for another discussion, though, as we're chatting more about how to make a robust timing function that could underly other timing functions (like spring() and steps() ) and possibly be an export format for programs like After Effects. I've seen a real need from designers, as I know you have. What do you think?

@notoriousb1t
Copy link

@notoriousb1t notoriousb1t commented Jul 19, 2016

It sounds good in theory, but I wonder if making a separate network call for each easing is a good idea. Even if you banked on HTTP2 to deliver it with the CSS file as an additional resource, it still would make CSS dependent on JS or a JS subset.

@vidhill
Copy link

@vidhill vidhill commented Jul 19, 2016

@rachelnabors just to clarify this wouldn't be a proposal for something that would be necessarily be a part of the Houdini spec.
I doubt it would be necessary for Houdini to work out to implement this.

I mentioned Houdini because I imagine that it'd this would be preferable for it to align with the style/spirit.

@notoriousb1t I understand the concern, the first thing that comes to mind is the question, what if the user has js disabled!?
As this js would not be allowed to do any direct dom manipulation (or anything else), all it should do is return a number
Would a different rule be able to be applied to this js?

It shouldn't be capable of doing anything 'nasty'

@birtles
Copy link
Contributor

@birtles birtles commented Jul 20, 2016

There's a long-term plan to support script-defined timing functions but we're waiting on certain houdini components to materialize first. I think the current name of the piece we're missing is a worklet -- basically we want a bit of script that runs with very limited context and no side effects that we can run on either the main thread or compositor.

@vidhill
Copy link

@vidhill vidhill commented Jul 20, 2016

@birtles I had a small chat about this on twitter with 'surma' and a few others,
I got some ideas on how I could re-do my example to be more inline with the Houdini conventions, and Surma recommended I send it in to the Houldini mailing list.

If this is already on the long term plans is the a point to doing this?
Would I be adding anything novel to the discussion?

-I'm new to the standards process, so genuinely don't know

@birtles
Copy link
Contributor

@birtles birtles commented Jul 21, 2016

@vidhill I think you should start a new issue for script-generated animations. This issue is pretty specifically about expanding the scope of timing functions that can be specified in a declarative manner. You could make that issue on this repository or on the web-animations one although I suspect it might be easier to start with Web Animations (since it is the lower level spec and already has a script API) and then we can layer CSS syntax on top later. In that issue, code examples using Houdini worklets would be useful.

@vidhill
Copy link

@vidhill vidhill commented Jul 21, 2016

Thanks,
will do that, and I will update my code examples.

@visiblecode
Copy link

@visiblecode visiblecode commented Apr 29, 2019

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 Beziers.

@tabatkins
Copy link
Member

@tabatkins tabatkins commented Apr 29, 2019

Note that step easings have already made a decision of whether the moment of transition uses prev or next value: they use the next value. So presumably we'd be consistent there, as the use-case for making it controllable seems extremely minimal - you'd only see the difference if you purposely advanced a paused animation to exactly that progress %.


Overall, uh, that sounds like a pretty good idea, and the fact that the curve is automatically c1-continuous is nice (unless you purposely drop to c0- or non-continuous by providing additional arguments). I like the physicality of being able to provide a velocity directly, which enables realistic-looking bounces really easily by just inverting the y velocity, like your example shows. (Versus chained beziers, which require much more guess-and-checking to get a realistic-looking bounce.)

@visiblecode
Copy link

@visiblecode visiblecode commented Apr 30, 2019

I think I can sweeten the pot a bit more for hand-authoring. Let's say there's also an auto option for velocity that picks a velocity for you.

For a smooth node with neighbors on both sides, auto would mean choose the velocity to get C2 continuity. That way, if you wanted you could spell out just the times and positions by hand, and automatically get buttery smooth motion.

In the remaining situations, auto would pick the velocity assuming no acceleration. That gives you an easy shorthand for linear motion, which would otherwise be a little clunky to do by hand.

@AmeliaBR
Copy link
Contributor

@AmeliaBR AmeliaBR commented Apr 30, 2019

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. In particular, I'd be interested to know if your definition of "automatic" velocity calculations matched Blender's automatic handles.

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, seems to use the rule proposed by @SebastianZ to convert arbitrary paths into functions.

@visiblecode
Copy link

@visiblecode visiblecode commented Apr 30, 2019

My take-away from the couple years I spent on this is:

  1. There's too much variation in the way different software represents animation curves to allow for a "master" representation that can seamlessly roundtrip with all of them
  2. Some popular ways of specifying animation curves only allow approximate implementations to begin with
  3. Where round-tripping the original representation isn't a concern, any animation curve can be converted to cubic splines with good fidelity (sometimes with added control points)
@visiblecode
Copy link

@visiblecode visiblecode commented Apr 30, 2019

brief overview on the math, I can go into more detail on specific things if you want

Every segment of a cubic spline translates to a cubic polynomial. There are a number of ways to represent a cubic polynomial, which are all exactly convertible (within the limits of floating point precision etc.), including:

  • the obvious way: ax3 + bx2 + cx + d
  • Hermite form: starting value, starting tangent, ending tangent, ending value
  • Bernstein form: starting value, two control values, ending value

The thing is, Bézier curves are based on Bernstein polynomials (the bezier handles map to the control values). The catch is that a 2D Bézier curve segment consists of two polynomials, one for x and one for y. For drawing curves on screen that's perfect, the two polynomials can be evaluated directly, independently, with all the usual advantages of cubics. Mathematically precise, versatile, and efficient to evaluate.

But, for uses like CSS's cubic-bezier(), you have to solve for the unique root of the x polynomial (with things constrained so there is one), and plug the result into the y polynomial. The root finding part isn't possible to do super efficiently, so in practice what most implementations of cubic-bezier() do is precompute a rough approximation and linearly interpolate over that. It works okay, but there's a big speed/accuracy tradeoff. Probably there's more variation between implementations than people realize, especially in extreme cases.

TBH, in general implementors would probably get better results (both in terms of accuracy and also performance) converting each cubic-bezier() segment to a cubic spline (of ~1-3 segments) rather than trying to approximate cubic-bezier() directly in realtime.

There are a bunch of other animation curve representations which get used as well, NURBS and so on. Some of these superficially resemble Béziers (they have similar handles, etc.), but don't allow exact conversion to/from them.

Blender's smoothing is a bit different to the auto thing I described above (which is based on spline interpolation). Blender's curves can still be approximated by cubic splines but you wouldn't use auto to do it.

@visiblecode
Copy link

@visiblecode visiblecode commented Apr 30, 2019

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, seems to use the rule proposed by @SebastianZ to convert arbitrary paths into functions.

What Greensock does is discard the parts of the path between where x starts decreasing to where it catches up again. I don't know the details of the implementation, but bezier path intersections tend to have rough edge cases to account for.

Obviously any reasonable easing representation should be able to support export of a "baked" representation (after pruning, etc). But should browsers be expected to implement on-the-fly pruning themselves?

@AmeliaBR
Copy link
Contributor

@AmeliaBR AmeliaBR commented Apr 30, 2019

But should browsers be expected to implement on-the-fly pruning themselves?

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. So that comment was more of an aside, going back to the discussion of the alternative.

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.

@flackr
Copy link
Contributor

@flackr flackr commented Apr 30, 2019

I have on occasion found myself wanting to supply a formula to express timing functions for example when I wanted to perfectly invert another timing function to implement an accelerated expanding reveal animation. 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?

@visiblecode
Copy link

@visiblecode visiblecode commented Apr 30, 2019

@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.

@visiblecode
Copy link

@visiblecode visiblecode commented May 1, 2019

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.

Apparently this isn't a requirement for Greensock. I chatted with the Greensock author about this today, and the way he explained it was instead of generating CSS and delegating to the browser, Greensock always drives animations from JavaScript.

Greensock has its own internal representation for easings that's optimized for efficiency vs perfect accuracy, and it always converts everything (CSS-style easings, SVG path easings, etc) to that internal representation before animating.

@visiblecode
Copy link

@visiblecode visiblecode commented May 1, 2019

Probably exporting animations from Blender is a better model use case.

@visiblecode
Copy link

@visiblecode visiblecode commented May 11, 2019

I had a thought this week -- knots in a spline are a lot like stops in a gradient, just
with value+slope instead of colors.

...what if the syntax for splines worked like the syntax for gradients?

animation-timing-function: cubic-spline(<position> <speed> <time%>, ...);

So for example:

animation-timing-function: cubic-spline(0 0 0%, 0.1 auto 25%, 0.5 auto 50%, 0.9 auto 75%, 1 0 100%);

Screenshot_2019-05-11 cubic-spline()(4)

It probably makes sense to support some shorthands.

To start with, using the rules for gradient stops, if you just want equal spacing you can leave off the knot times/percentages:

animation-timing-function: cubic-spline(0 0, 0.1 auto, 0.5 auto, 0.9 auto, 1 0);

It'd probably also make sense to make speed optional (defaulting to auto):

animation-timing-function: cubic-spline(0 0, 0.1, 0.5, 0.9, 1 0);

(Both of these give the same result as the original above.)

That feels pretty nice.

If we go with the same rules as for gradients, you can create abrupt changes by doubling up knots:

animation-timing-function: cubic-spline(0, 1 50%, 1 50%, 0);

Screenshot_2019-05-11 cubic-spline()(1)

animation-timing-function: cubic-spline(0.5, 1 50%, 0 50%, 0.5);

Screenshot_2019-05-11 cubic-spline()(2)

animation-timing-function: cubic-spline(1 0, 0 -3 50%, 0 3 50%, 1 0);

Screenshot_2019-05-11 cubic-spline()(3)

EBNF syntax for this idea might look something like:

<cubic-spline-easing-function> = cubic-spline( <cubic-spline-knot-list> )

<cubic-spline-knot-list> = <cubic-spline-knot> [, <cubic-spline-knot># ]?
<cubic-spline-knot> = <cubic-spline-knot-position> <cubic-spline-knot-speed>? <cubic-spline-knot-time>?

<cubic-spline-knot-position> = <number>
<cubic-spline-knot-speed> = auto | <number>
<cubic-spline-knot-time> = <percentage>
@visiblecode
Copy link

@visiblecode visiblecode commented May 11, 2019

Also, here's a bounce easing I prepared by hand:

animation-timing-function: cubic-spline(0 0, 1 50%, 1 50%, 0.5, 1 75%, 1 75%, 0.75, 1 87.5%, 1 87.5%, 0.875, 1 93.75%, 1 93.75%, 0.9375, 1 96.8%, 1 96.8%, 0.968, 1 98.4%, 1 98.4%, 1);

Screenshot_2019-05-11 cubic-spline()(5)

Edit: Also, a handmade spring easing.

animation-timing-function: cubic-spline(0 0, 1.5 0 50%, 0.75 0 75%, 1.125 0 87.5%, 0.9375 0 93.75%, 1.031 0 96.8%, 0.984 0 98.4%, 1 0);

Screenshot_2019-05-11 cubic-spline()(6)

@birtles
Copy link
Contributor

@birtles birtles commented May 13, 2019

Those are neat diagrams and the effects you've produced look great. They seem to cover the different use cases well.

As someone who is not very familiar with gradients (I need to look it up every time) I don't find the parallel with gradient syntax particularly helpful. In particular, putting the "y" value (<cubic-spline-knot-position>) before the "x" offset (<cubic-spline-knot-time>) feels back-to-front compared to how I'm used to thinking with regards to keyframe offsets. However, that may be just me, and given that these easing functions may be used with gradients, aligning the syntax probably makes sense.

Currently all easing functions go from (0,0) to (1,1). I'm unsure if we should break that invariant or not (as this syntax currently allows). I seem to recall it had unfortunate implications in the realm of GroupEffects (where timing functions are effectively layered on top of one another) but perhaps it's ok.

@visiblecode
Copy link

@visiblecode visiblecode commented May 13, 2019

Since it's already allowed in a more limited way, letting the dependent variable (progress) to go outside the 0..1 range shouldn't be much of a problem.

For the independent variable (time), though -- I'd imagined we'd just use the section of the timing function between 0 and 100%, regardless of where the first/final knots are, extrapolating past the end knots with straight lines if necessary.

animation-timing-function: cubic-spline(0 0 30%, 1 0 66%);

Screenshot_2019-05-12 cubic-spline()

@visiblecode
Copy link

@visiblecode visiblecode commented May 13, 2019

I'm not super attached to the gradient syntax, it just seemed like a nice opportunity for syntactic uniformity with the rest of CSS.

@birtles
Copy link
Contributor

@birtles birtles commented May 13, 2019

Since it's already allowed in a more limited way, letting the dependent variable (progress) to go outside the 0..1 range shouldn't be much of a problem.

Right, that part is fine.

For the independent variable (time), though -- I'd imagined we'd just use the section of the timing function between 0 and 100%, regardless of where the first/final knots are, extrapolating past the end knots with straight lines if necessary.

What I'm more concerned about is when f(0) != 0 or f(1) != 1. There certainly used to be places where we assumed that. With step-start you can already have f(0) != 0 but only when the "before flag" is false.

I recall that in the past that invariant proved useful but perhaps it's fine now. (It may have been when we were trying to chain timing functions together, or when we were trying to invert them in order to work out when to dispatch events -- but we don't do either of those things anymore).

@visiblecode
Copy link

@visiblecode visiblecode commented May 14, 2019

What I'm more concerned about is when f(0) != 0 or f(1) != 1. There certainly used to be places where we assumed that. With step-start you can already have f(0) != 0 but only when the "before flag" is false.

I recall that in the past that invariant proved useful but perhaps it's fine now. (It may have been when we were trying to chain timing functions together, or when we were trying to invert them in order to work out when to dispatch events -- but we don't do either of those things anymore).

It'd be worth grounding out on whether there are any lingering issues with lifting this restriction, for both Gecko and WebKit. As long as the restriction is in place, there's a whole family of complex animations left that can't be expressed except the "long way", with multiple keyframes.

For example:

Screenshot_2019-05-14 cubic-spline()(1)

Without the requirement that f(0) == 0 and f(1) == 1, this animation could be expressed the same way as other complex animations (using the gradient-style strawman syntax):

@keyframes bouncy {
    0% {
        transform: translate(0px);
        animation-timing-function: cubic-spline(0, 1, 0 33%, 0 33%, 0.33, 0 66%, 0 66%, 0.11, 0);
    }
    100% {
        transform: translate(90px);
    }
}

But, if the restriction were in force, for certain animations like this one you'd be forced to fall back to something like:

@keyframes bouncy {
    0% {
        transform: translate(0px);
        animation-timing-function: cubic-spline(0, 1 0);
    }
    16% {
        transform: translate(90px);
        animation-timing-function: cubic-spline(0 0, 1);
    }
    33% {
        transform: translate(0px);
        animation-timing-function: cubic-spline(0, 1 0);
    }
    49% {
        transform: translate(30px);
        animation-timing-function: cubic-spline(0 0, 1);
    }
    66% {
        transform: translate(0px);
        animation-timing-function: cubic-spline(0, 1 0);
    }
    82% {
        transform: translate(10px);
        animation-timing-function: cubic-spline(0 0, 1);
    }
    100% {
        transform: translate(0px);
    }
}

(There's still a somewhat shorter way to write this, which I'll leave as an exercise for the reader because it requires a re-parameterization that's annoying to do by hand.)

@AmeliaBR
Copy link
Contributor

@AmeliaBR AmeliaBR commented May 14, 2019

@visiblecode How would you handle transitions, or filled animations, if the easing function doesn't reach the the target “end” value at the end time? Would the value jump suddenly to match?

@visiblecode
Copy link

@visiblecode visiblecode commented May 14, 2019

@visiblecode How would you handle transitions, or filled animations, if the easing function doesn't reach the the target “end” value at the end time? Would the value jump suddenly to match?

Yes, similar to the current situation with some step easings.

Edit: For fills, I guess it might make sense to hold the last computed value to make animations like the above possible. Which would be different to the behavior for step.

@birtles
Copy link
Contributor

@birtles birtles commented May 16, 2019

Edit: For fills, I guess it might make sense to hold the last computed value to make animations like the above possible. Which would be different to the behavior for step.

Right, for fills it is already possible to fill at the mid-point of an interval by using animation-iteration-count: 0.5 for example.

@visiblecode
Copy link

@visiblecode visiblecode commented May 16, 2019

That's an interesting point. I think we can get away without having any special fill behavior.

For use cases involving complex exported animations, multiple intermediate keyframes would be the norm anyhow.

@css-meeting-bot
Copy link
Member

@css-meeting-bot css-meeting-bot commented Jun 6, 2019

The CSS Working Group just discussed easing timing functions.

The full IRC log of that discussion <fremy> Topic: easing timing functions
<astearns> github: https://github.com//issues/229
<fremy> AmeliaBR: this is another old issue, that had a lot of discussion for a while, but every so often somebody finds it again, and revives the issue
<fremy> AmeliaBR: the issue is that all the easing functions are only continuous curves
<fremy> AmeliaBR: you can use strong coefficients to create a slight overshoot, but that doesn't allow rebounds
<fremy> AmeliaBR: so the request is to have more complex functions
<fremy> AmeliaBR: most animation software have ways to create those functions, but now they can't be exported to css
<hober> q+
<fremy> AmeliaBR: and they have to be exported to huge keyframe sequences which are difficult to maintain and understand
<hober> https://lists.w3.org/Archives/Public/www-style/2016Jun/0181.html
<astearns> https://github.com//issues/229#issuecomment-492367598
<fremy> AmeliaBR: there is a proposal to use cubic bezier but it allows too much for what we want
<fremy> AmeliaBR: there is also a more recent proposal, and I happen to like it
<dbaron> cubic beziers as defined currently are well-defined functions since we give only 2 of the 4 control points and the x values are constrained to [0,1]
<fremy> AmeliaBR: but there is also the option of using the cubic bezier syntax and let the browser fix that up if the function isn't pure
<astearns> ack hober
<fremy> AmeliaBR: so our first question, what should we do first, get a great syntax or extend the type of syntax we have now
<hober> spring(mass stiffness damping initialVelocity)
<fremy> hober: we think this is a good idea
<fremy> hober: we like this syntax, and we are all for it
<fremy> astearns: any other comment?
<fremy> heycam: what's the unit that this proposal used?
<fremy> heycam: css values should have the answer
<flackr> q+
<fremy> astearns: dbaron pointed out on irc that cubic-bezier can work as functions
<astearns> ack flackr
<fremy> AmeliaBR: yes because we remove some parameters, but as you try to add expressivity, it's difficult to maintain that
<majidvp> q+
<astearns> ack majidvp
<fremy> majidvp: one thing I like about this idea, it's possible to approximate a spring using the proposal, which is great because other we have to specify ourselves all the types of bounds we want, but authors will still want more
<hober> s/we think this is a good idea/dean proposed a spring timing function a few years ago. we're supportive of having such a thing./
<fremy> AmeliaBR: yes, if we have a generic expression syntax that handles many things, we can get spring to be an alias to that
<hober> s/we like this syntax, and we are all for it//
<argyle> 😍
<fremy> astearns: I don't see much desire to discuss the precise syntax, but there is some interest
<fremy> fantasai: should we add somebody to edit the spec?
<fremy> astearns: but I don't see enough interest to add this to a spec
<fremy> myles_: AmeliaBR what are you trying to achieve here?
<fremy> AmeliaBR: get agreement that a generic mechanism would be great to add to easing-2
<fremy> myles_: my problem with the generic approach, is that the end result is just complex math, and doesn't explain what the end result should look like
<fremy> myles_: which is why I prefer `spring` because it has clear intent
<fremy> myles_: also, as designer, I think I would draw what I want in a software, as a piece-wise function
<astearns> ack dbaron
<fremy> myles_: and that is not easy to express as a cubic-bezier
<fremy> dbaron: I think adding new things in that space is reasonable, but I think I would want to weight the implementation cost, but in general I'm in favor of adding expessivity in the spec here
<fremy> AmeliaBR: the last proposal has very nice pictures, and seem well accepted
<dbaron> dbaron: nice pictures and few/no equations
<fremy> astearns: one way to make progress is to find the contributor that submitted the various comments, and convince that person to collect them in a spec in wicg
<fremy> AmeliaBR: I'm willing to try to get that to happen, if there are other people interested they are welcome to join me
<majidvp> q+
<fremy> flackr: I'm interested in the space as well, but didn't evaluate
<fremy> flackr: the current proposal
<astearns> ack majidvp
<fremy> flackr: but my attention will be about ease of write, and ease of parse
<fremy> fantasai: and ease-of-read as well
<fremy> flackr: yes
<fremy> majidvp: i would also want to note that if you have an houdini approach, we can allow any js function, then sample it
<fremy> majidvp: previously houdini was a big leap in the space
<fremy> majidvp: but right now, we have a lot of things ready, and this would be easily doable
<fremy> hober: I'm weary of putting off very desirable features to js
<fremy> majidvp: I'm not saying we shouldn't do a declarative approach, but I don't see why both can't be pursued at the same time
<fremy> hober: sure
<fremy> myles_: we are fine with a houdini approach
<fremy> myles_: but that shouldn't prevent us from delivering features that are directly relevant to authors
<hober> s/to js/until houdini is ready/
<myles_> s/we are fine with a houdini approach/the presence of houdini doesn't allow us to stop making good features for our users/
<majidvp> I agree with that sentiment :)
<fremy> AmeliaBR: ok, so the conclusion is that we are going to try to gather a community to make this happen, thanks everyone for the feedback
<fremy> <br /> (after which we would talk about motion-blur)
@visiblecode
Copy link

@visiblecode visiblecode commented Jun 7, 2019

dbaron: nice pictures and few/no equations

I wasn't sure if spelling out the equations would be necessary at this stage. As mentioned upthread, the piecewise curves here are supposed to be Cubic Hermite splines. They are a standard thing and very closely related to Bezier curves.

Hermite splines can be given as a sequence of (t, p, m) triples, corresponding to the knots. In this context those correspond to (time, progress, velocity), with time and progress ranging between 0 and 1, apart from under/overshoot.

(n.b. the strawman CSS syntax from earlier gives t last, and as a percentage, just because it's trying to imitate CSS gradient syntax.)

I'll use t0 to mean the t from the first knot, t1 from the second knot, and so on...

For evaluating the curve in between knots, it's probably easiest to convert the segments to Bernstein form. (Bezier curves are made of polynomials in Bernstein form.)

Converting one Hermite segment, between knots n and n+1, to Bernstein form and re-parameterizing for the unit interval:

Δtn = tn+1 - tn

C0 = pn
C1 = pn + mn * Δtn / 3
C2 = pn+1 - mn+1 * Δtn / 3
C3 = pn+1

Evaluating the converted segment for some t, using De Casteljau's algorithm, as is commonly done for Beziers:

lerp(a, b, x) = (1 - x) * a + x * b

tunit = (t - tn) / Δtn

B0 = lerp(C0, C1, tunit)
B1 = lerp(C1, C2, tunit)
B2 = lerp(C2, C3, tunit)

A0 = lerp(B0, B1, tunit)
A1 = lerp(B1, B2, tunit)

result = lerp(A0, A1, tunit)

One non-standard thing is that I'm allowing zero length segments (where tn == tn+1) to represent abrupt changes in the curve; these trivial segments shouldn't get evaluated.

When I have a chance, I'll follow up on how to compute unspecified mn values (missing or auto in the strawman syntax).

@visiblecode
Copy link

@visiblecode visiblecode commented Jun 7, 2019

Missing mn values (slopes) can be worked out by solving a system of linear equations with an equation per knot.

If a knot's slope is already known, the equation is trivial:

mn = the slope

Otherwise, assuming:

Δtn = tn+1 - tn
Δpn = pn+1 - pn

It's a choice between:

A. mn = 0
B. 2 * mn / Δtn + mn+1 / Δtn = 3 * Δpn / Δtn2
C. mn-1 / Δtn-1 + 2 * mn / Δtn-1 = 3 * Δpn-1 / Δtn-12
D. mn-1 / Δtn-1 + 2 * mn * (1 / Δtn-1 + 1 / Δtn) + mn+1 / Δtn = 3 * (Δpn-1 / Δtn-12 + Δpn / Δtn2)

Which equation to use depends on the knot's neighbors:

Previous Knot Next Knot Equation
none none A
none same t A
same t none A
none different t B
same t different t B
different t none C
different t same t C
different t different t D

This choice of equations amounts to doing standard spline interpolation for each unbroken section of curve with unknown slopes.

The tridiagonal matrix algorithm is a good fit for solving the resulting system of equations and is easy to implement.

@AmeliaBR
Copy link
Contributor

@AmeliaBR AmeliaBR commented Jun 7, 2019

Thanks for the equations, @visiblecode !

What did you think about turning this into a WICG proposal? That would have two benefits:

  1. People would be able to edit and keep track of the final proposal without reading this entire thread!
  2. It would involve you confirming that you're contributing all your intellectual property claims in your proposal under a licence that is compatible with W3C specs.

Myself and @argyleink have said we'd be able to help coordinate & deal with the formatting aspects of the proposal, but we'd need the IP contributions sorted out first.

@visiblecode
Copy link

@visiblecode visiblecode commented Jun 7, 2019

Okay, I'm willing to give it a shot, though it may be a couple weeks before I can get back to you.

@argyleink
Copy link
Contributor

@argyleink argyleink commented Aug 1, 2019

wanted to share for potential reference and relevance https://github.com/lunelson/split-ease

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
You can’t perform that action at this time.