d3 / d3-ease

Easing functions for smooth animation.

d3-ease

Easing is a method of distorting time to control apparent motion in animation. It is most commonly used for slow-in, slow-out. By easing time, animated transitions are smoother and exhibit more plausible motion.

Resources

• Documentation
• Examples
• Releases
• Getting help

d3-ease's Issues

update docs with npm version

could we please add a link to the npm page in the repo readme. I can submit a pr with the updated docs just want an A okay that's fine to do

https://www.npmjs.com/package/d3-ease

bounce optional params

bounce and bounceIn are documented as taking one parameter, but bounceOut and bounceInOut take up to three. Either these extra params should be documented for the first two functions, or they're copypasta from backIn[Out] and should be removed.

Thanks, and sorry for nitpicking.

README needs API reference.

Rename ease(type[, parameters…]) to bind?

Don’t ignore NaN parameters?

We currently ignore null, undefined and NaN easing parameters. I understand why we should ignore null and undefined, but ignoring NaN seems unnecessary. (I suppose it’s consistent with how d3-arrays ignores values, though.)

broken Map polyfill

I mistakenly opened this issue earlier as "transpile es6 -> es5". After digging into the problem I was having more, I realized that the module is being transpiled, but that the Map polyfill is not being correctly, or maybe completely applied. Phantomjs tests break in any project this library is included in.

Easing/Transitioning in Chrome

I think this issue should probably be moved elsewhere, I'm just not really sure where else to put it yet. I'm more just trying to gather thoughts than anything else as I feel like other d3 users must have ran into this issue as well...

I have some code that translates a g element via d3-transition and d3-ease:

d3.select(this.container)
    .transition()
    .duration(1200)
    .ease(Easing)
    .attrTween('transform', () => {
        var i = Interpolate(0, 360)

        return function(t) {
            return `translate(105, 107.5) rotate(${i(t)})`
        })
    })
    .on('end', (d, i) => {
        if (this.props.loading) this._rotate() // Recalls this function
           else this._slideIn() // Ends the animation
    })

This code works flawlessly in Firefox and used to in Chrome as well, however after a recent Chrome update within the last year or so the transition started to look very odd. By this I mean instead of rotating 360 degrees and bouncing upon completion, it does this back and forth rocking while slowly orbiting around.

When I inspect the DOM, I see the rotate() values within the transform attribute being modified properly. Even slowing the animation doesn't help and, in fact, I've seen some other odd behaviors (such as rewinding when moving from 360 => 0) while trying to debug.

Again, I think this is probably not an issue with this repo or d3 in general and I'm happy to move elsewhere that would make more sense.

LICENSE: Is ISC not BSD-3

On Github the license is labelled as BSD-3 however the LICENSE file wording matches ISC.
The license in the link matches the license in d3-ease
https://opensource.org/license/isc-license-txt

Need an ease interface.

An interface is needed to disambiguate transition.ease(ease) from transition.ease(function), where the latter is a function that returns an easing function, thereby allowing different easing functions to be used for different nodes in a transition. This is the same issue that lead to the creation of the symbol type interface in d3-shape, which is useful for applying a categorical symbol encoding to a scatterplot.

Admittedly, I don’t anticipate a lot of demand for customizing the easing function per node, but if we didn’t support it, the inconsistency is likely to lead to occasional confusion.

It’d still be nice if you could have optional parameters, though. Not sure how to do that…

transition.ease(d3.easePolyIn, 2);

Maybe if there’s more than one argument, it automatically gets converted to this?

transition.ease(d3.easePolyIn(2));

Well actually that wouldn’t work, because if you didn’t specify the optional argument, then the parameterizable easing function factory would get invoked separately for each node.

transition.ease(d3.easePolyIn); // Oops, an ambiguous function again!

Alternatively, the non-parameterizable easings could still be functions that return easing instances, so these would be equivalent…

transition.ease(d3.easeLinearIn);
transition.ease(d3.easeLinearIn());

But that means you’d need to do some manual easing, you’d need to change this:

var t = d3.easeCubicInOut(0.123);

To this:

var t = d3.easeCubicInOut().ease(0.123);

Which is a little verbose. (And slower, unless you stash the result of d3.easeCubicInOut() outside of your animation loop.) But then the transition.ease API is probably going to see wider use than the d3-ease API, and it’s not like the proposed API is bad. You can approximate the old API like so:

var cubicInOut = d3.easeCubicInOut().ease;

var t = cubicInOut(0.123);

Remove non-in aliases.

I think we should remove exp as an alias for expIn and so on. For example, with cubic easing, you’re more likely to want cubicInOut than cubicIn.

Consider using a more generic easing library

Shameless self promotion - https://github.com/bcherny/penner

Return values of 0 and 1 are not always as expected

I ran into an issue animating with easeExpInOut where the end result was not exactly 1. The readme states "A good easing type should return 0 if t = 0 and 1 if t = 1", but a few of these do not.

https://observablehq.com/@danmarshall/d3-easing-at-0-1

easeBack 0: 0, 1: 1
easeBackIn 0: 0, 1: 0.9999999999999998
easeBackInOut 0: 0, 1: 1
easeBackOut 0: 2.220446049250313e-16, 1: 1
easeBounce 0: 0, 1: 1
easeBounceIn 0: 0, 1: 1
easeBounceInOut 0: 0, 1: 1
easeBounceOut 0: 0, 1: 1
easeCircle 0: 0, 1: 1
easeCircleIn 0: 0, 1: 1
easeCircleInOut 0: 0, 1: 1
easeCircleOut 0: 0, 1: 1
easeCubic 0: 0, 1: 1
easeCubicIn 0: 0, 1: 1
easeCubicInOut 0: 0, 1: 1
easeCubicOut 0: 0, 1: 1
easeElastic 0: 0, 1: 1.00048828125
easeElasticIn 0: -0.00048828124999999875, 1: 1
easeElasticInOut 0: -0.00024414062499999938, 1: 1.000244140625
easeElasticOut 0: 0, 1: 1.00048828125
easeExp 0: 0.00048828125, 1: 0.99951171875
easeExpIn 0: 0.0009765625, 1: 1
easeExpInOut 0: 0.00048828125, 1: 0.99951171875
easeExpOut 0: 0, 1: 0.9990234375
easeLinear 0: 0, 1: 1
easePoly 0: 0, 1: 1
easePolyIn 0: 0, 1: 1
easePolyInOut 0: 0, 1: 1
easePolyOut 0: 0, 1: 1
easeQuad 0: 0, 1: 1
easeQuadIn 0: 0, 1: 1
easeQuadInOut 0: 0, 1: 1
easeQuadOut 0: 0, 1: 1
easeSin 0: 0, 1: 1
easeSinIn 0: 0, 1: 0.9999999999999999
easeSinInOut 0: 0, 1: 1
easeSinOut 0: 0, 1: 1

Not sure if this is a bug or not, but hopefully this helps anyone else with this issue.

Accelerate, then coast?

Shown here:
http://bl.ocks.org/mbostock/10342273
http://bl.ocks.org/mbostock/10343037
http://bl.ocks.org/mbostock/10395901

Not sure if it’s totally useful, though.

Symbols, not strings?

See d3/d3-shape#23 d3/d3-shape#29.

Cubic Bézier easing?

See d3/d3#1982. The only problem is that it’s kind of a pain to evaluate a cubic Bézier for y given x (rather than t), so it probably requires a numerical solution.

README references obsolete APIs.

Right now several methods that use .exponent() have demo images that document their usage with a second argument specifying the exponent as an argument.

I think this refers to an older API of this module, and we'll need to update the images.

Register with bower.