Hacker News Reader

Comment by kvdveer | Hacker News Reader

That interpolation (which isn't a lerp) is framerate dependent. On slower devices, it will be exponentially slower, on faster devices it's going to be near-instant.

Anytime you see an interpolation that does not use a time-component, that interpolation will be (wildly) different on different devices.

View on HN

IDK, on my fast desktop computer it's still a slow and bad simulation of inertia.

It shouldn't matter if it's a fast desktop or slow mobile (unless it's not keeping up, which is unlikely in these examples); what matters is the display rate on these devices. The demos feel very fast in a 250Hz monitor when compared to a 60Hz one.

That's right. These demos are, as they should be, using requestAnimationFrame [1]. The docs have "Warning: Be sure to always use the first argument (or some other method for getting the current time) to calculate how much the animation will progress in a frame, otherwise the animation will run faster on high refresh rate screens."

Though there are cases like iOS cross-origin frames where it's throttled to 30fps [2] for power-saving reasons.

[1] https://developer.mozilla.org/en-US/docs/Web/API/window/requ...

[2] https://bugs.webkit.org/show_bug.cgi?id=168837

Sure, but this is a demo seemingly targeted at people who design interactions, not definitive documentation for front-end developers. In any animation environment with this much control, taking the tick delta or some equivalent into consideration is trivial-- a couple of lines at most. But adding implementation details irrelevant to the core mechanism unnecessarily increases the cognitive load for folks who don't parse code for a living.

But...the implementation is such that you can't take into account the number of ticks.

Every time you call it, it moves by the same amount.

This is how people did animations back when PCs were always the same speed, so you didn't need to worry about frame rate changes. And it's why they had to add a "turbo" button to the next generation of PCs...because many games weren't playable when the clock rate was nearly 2x the previous generation.

So it's an example that can't be used. The details aren't irrelevant. They're crucial.

So unless the goal is a fluff article that isn't actually useful for anything, it's deceptive. Run these animations on a 200FPS screen and they'll look very different than at 60FPS.

They're crucial for developers implementing this technique. They're irrelevant for designers that only need to know that this is possible and what it looks/feels like to the users.

Reply on news.ycombinator.com