3 ms·

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-inst

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.

tempodox 4y ago
IDK, on my fast desktop computer it's still a slow and bad simulation of inertia.
- mkishi 4y ago
  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.
  - jefftk 4y ago
    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/requestAnimationFrame https://developer.mozilla.org/en-US/docs/Web/API/window/requ... [2] https://bugs.webkit.org/show_bug.cgi?id=168837 https://bugs.webkit.org/show_bug.cgi?id=168837
DrewADesign 4y ago
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.
- SomeCallMeTim 4y ago
  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.
  - DrewADesign 4y ago
    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.

tempodox 4y ago

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

mkishi 4y ago
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.
- jefftk 4y ago
  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/requestAnimationFrame https://developer.mozilla.org/en-US/docs/Web/API/window/requ... [2] https://bugs.webkit.org/show_bug.cgi?id=168837 https://bugs.webkit.org/show_bug.cgi?id=168837

DrewADesign 4y ago

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.

SomeCallMeTim 4y ago
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.
- DrewADesign 4y ago
  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.