search

haltu / muuri

Infinite responsive, sortable, filterable and draggable layouts
https://muuri.dev
MIT License
10.8k stars 644 forks source link

Smoother transition between animations #328

Open niklasramo opened 5 years ago

niklasramo commented 5 years ago

Canceling animation mid-flight and starting up a new animation can produce a noticeable sharp jump since the animation's playback position on the main thread may have drifted from the playback position in the animation thread. It would be nice if the item smoothly transformed from current animation to the next, somehow...

One way could be to smoothly stop the current animation over e.g. 5 frames slowing down animation's playback rate. Another way could be to .pause() current animation and in the next frame check what are the current values. This way the drifting in the animation thread might be negated.

thednp commented 2 years ago

Have you tried to test this case without web workers?

niklasramo commented 2 years ago

@thednp Yes, have tried it with and without, but web workers should not be really affecting this issue. It's the animation thread that sometimes moves a bit ahead of the main thread. So when you query the current element position from DOM and then try to stop the element animation and set the queried position via element.style the element nudges a bit sometimes, which indicates that the animation thread had still a bit time to move the animated element before it was stopped and the given position via element.style.

I guess you could work around that issue by first e.g. stopping the animation and after that querying the element positions when you are sure that the animation thread is not moving the element anymore. I remember trying it this way too, but for some reason it didn't help at the time either. Might need some more looking into.

thednp commented 2 years ago

I understand exactly what you mean, I've worked on my JS animation engine. Let me give you a quick example to frame your mind: (1) you create 1000 tweens and start animation right away presents the user with a different animation than (2) creating 1000 tweens and starting animation all together when done creating them, which is the desired outcome.

I agree with your initial theory, the best solution I can think of is pausing the animation, but allow it to "ease out" for a couple more pixels depending on the velocity, then get the {x, y} when completely frozen so when you resume animation it looks like magic. The "ease out" we're referring to is something GSAP has implemented with their pointer event plugins, which to put it simply, on release there is a kind of inertia effect.

If you decide to go ahead, a pause method for the ItemLayout class, we might work on a method which accepts an argument with enough scope to have it dance for you every day of the week.

Overall, I like how the animation works, I have no complaint about that, and I'm thinking perhaps this might be a pointless and time consuming effort, I think consistency is more important.

niklasramo commented 2 years ago

Yep, this issue is not a major concern and pretty much unnoticeable unless you have hundreds of items animating. Still, would be nice to get rid of the nudge at some point if that's possible without too much extra code. Thanks for the input here :)

thednp commented 2 years ago

After a bit of rest, I came to the realization that I've seen this before.

Here is a small hint, since the issue is about getting the coordinates "mid-flight" on items that scale up/down in your default demo, Popper.js implements a custom getBoundingClientRect which takes into account the scale of the element, have a look. I believe it might part of the solution. I mean if the [pause(), get {x,y}, resume] plan fails, plan B is to also test this gem I found.