Hacker News Reader

Comment by iainmerrick | Hacker News Reader

I don't see much discussion here of the crucial point, which is that this isn't just another easing curve or smoothstep() between 0 and 1, it's a stateless method that handles pretty much any inputs in a regular way. That's really useful!

If you've used CSS transitions you'll have encountered the problem this solves. Okay, my duration is 400ms -- but why 400? Shouldn't it depend on how far it has to move?

As others have noted, exponential smoothing has a different problem, that it asymptotically approaches but never quite reaches its destination. The obvious fix is to stop animating when the step gets below some threshold, but that's inelegant.

When using a similar method for inertial scrolling, I've found it useful to add a (pseudo-)friction term. This offsets the exponential, and effectively works as a minimum speed. Here it is in Desmos: https://www.desmos.com/calculator/98ufbuzxhj

View on HN

> As others have noted, exponential smoothing has a different problem, that it asymptotically approaches but never quite reaches its destination. The obvious fix is to stop animating when the step gets below some threshold, but that's inelegant.

This is off the cuff, but you might be able to fix this as follows: Interpret exponential smoothing as a ODE on the distance to the target. Call that distance D. Then exponential smoothing is the Euler update for dD/dt=-C*D. (the constant C>0 being a speed parameter) The issue you bring up is basically the fact that the solutions to the ODE are D(t)=A*exp(-C*t), which is asymptotic to zero as t->oo, but never reaches zero. Now, the fix is to replace the ODE with one that goes to zero in finite time. e.g. dD/dt=-C*sqrt(D). (Solutions are half-quadratic. i.e. they are quadratic for a bit then stay zero once you hit zero.) The Euler update for this is stateless like you wanted.

> The obvious fix is to stop animating when the step gets below some threshold, but that's inelegant.

Why? It's simple, easy to implement and validate, and provides the desired visual impact. Seems perfectly elegant to me.

> If you've used CSS transitions you'll have encountered the problem this solves. Okay, my duration is 400ms -- but why 400? Shouldn't it depend on how far it has to move?

It seems to me that the "speed" parameter in the exponential function has the same issue, does it not?

If you use the version somebody else here mentioned, “move 90% of the way to the destination in 80ms”, does that make more sense? (I think it’s equivalent, just a change of units.)

But can't you then also change the units on the linear animations? "move 40px/s until you reach the destination"

I don't think there's any way to do that in pure CSS (which is what I was comparing to). You can specify transition duration, but not speed.

Ah, I think I considered the article to be a supposed improvement to CSS animations - in which case both exponential smoothing and px/s transitions would be independent improvements.

Reply on news.ycombinator.com