search

framer / motion

Open source, production-ready animation and gesture library for React
https://framer.com/motion
MIT License
22.41k stars 740 forks source link

Did animation timing/easing defaults change between v1 and v2? #772

Closed subvertallchris closed 3 years ago

subvertallchris commented 3 years ago

Hey guys, very sorry to ignore the template but I don't have a great way of immediately reproducing this.

I'm upgrading from 1.11.1 to 2.6.15 and my animations look different. For the most part, it's as if the default easing transition has changed. Things look like they speed up just towards the end, or animations that used to look synchronized due to timings seem slightly out of sync.

The changelog doesn't indicate anything about this changed but it definitely seems like something did. Upgrade notes don't seem to indicate anything we should do as part of our upgrade, either. Am I overlooking something obvious?

If we determine that this is a bug, I can see about putting together sandboxes to reproduce. I'm also happy to link you to some videos demonstrating differences if you'd like to send me an email address.

(Changed the title a few times cause multitasking and brain is bad no good working, sorry 🧠)

mattgperry commented 3 years ago

Could you change versions to 2.5.0 and compare those to 1.11? It would help me narrow down what could have changed. Are these animations springs or tweens?

On Tue, 22 Sep 2020 at 20:55, Chris Grigg notifications@github.com wrote:

Hey guys, very sorry to ignore the template but I don't have a great way of immediately reproducing this.

I'm upgrading from 1.11.1 to 2.6.15 and my animations look different. For the most part, it's as if the default easing transition has changed. Things look like they speed up just towards the end, or animations that used to look synchronized due to timings seem slightly out of sync.

The changelog doesn't indicate anything about this changed but it definitely seems like something did. Upgrade notes don't seem to indicate anything we should do as part of our upgrade, either. Am I overlooking something obvious?

If we determine that this is a bug, I can see about putting together sandboxes to reproduce. I'm also happy to link you to some videos demonstrating differences if you'd like to send me an email address.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/framer/motion/issues/772, or unsubscribe https://github.com/notifications/unsubscribe-auth/AB34WKUJQRFWK2UYZL43ZYDSHDXJVANCNFSM4RWEANHA .

subvertallchris commented 3 years ago

Sure, I'll check that now. I've never set animation type, so I think they should all be tweens, right?

subvertallchris commented 3 years ago

The change occurs in 2.5.0. I tested 2.4.3, 2.4, 2.3, and 2.0 -- they all behave the same as 1.11. Happy to provide more info however I can, it's just a little tricky because all my affected areas are parts of really complicated components that I can't just drop into a sandbox.

Looking at the diff between 2.4.3 and 2.5.0, I see some changes in getChildrenAnimations. All of these affected areas use variants and have children with animations, so maybe it's in there?

manfromanotherland commented 3 years ago

Noticed the same when upgrading from 2.4. to 2.6., animations were much slower on instances where I had set a custom spring animation. I removed/tweaked the custom spring animations to fix the issue.

emadabdulrahim commented 3 years ago

Noticed a similar issue upgrading from 2.3.0 to 2.6.15, my custom spring with adjusted dampening and stiffness is animating differently. I think it's animating faster and not as smooth.

sami616 commented 3 years ago

I have also noticed that my previous 'springy' animations now look more like very fast timing animations. I've migrated from 2.4.1 -> 2.6.15

mattgperry commented 3 years ago

There was an upgrade to Popmotion 9 sometime with 2.6.x. Popmotion 9 fixed a bug with critically damped springs and correctly implemented overdamped springs so it is possible that springs feel different.

Going to close but please reopen with CodeSandbox examples.

subvertallchris commented 3 years ago

Are springs the default mode of changing positions?

sami616 commented 3 years ago

@subvertallchris i believe so, however they don't appear to be for layout animations. (Definitely not shared layouts AFAIK)

subvertallchris commented 3 years ago

I see. The docs are a little hard for me to make sense of here. Regarding Tween: "If any non-orchestration transition values are set without a type property, this is used as the default animation." Regarding Spring: "Set type to "spring" to animate using spring physics for natural movement. Type is set to "spring" by default." I'm unsure what qualifies as a "non-orchestration transition value."

Either way, it seems that messing with the ease value on my end can control what I'm seeing. It's definitely different but our designer gave on ok to how it looks now so I think we'll just address it in our code, so I won't be opening a new issue. I do think that the changelog should warn people about possible animation changes in 2.6.x, regardless.

sami616 commented 3 years ago

at a closer inspection, it seems as if with the latest version, scale animations don't work with springs, even if you pass your own spring it always looks like a tween.

mattgperry commented 3 years ago

https://www.framer.com/api/motion/animation/#transitions

scale is by default a spring.

If you want to explicitly set a transition you should also define its type otherwise it'll become a tween. If you have an example of other behaviour feel free to throw in a CodeSandbox.

sami616 commented 3 years ago

Got to the bottom of it, i was animating scale from 0.8 - 1. Which was enough (on the older version of framer motion) for a spring effect. However, on the newer version nada.

Solved this by lowering my scale starting point 0.5. This is most likely due to the springs feeling different since popmotion 9 was introduced i image?

niwsa commented 3 years ago

On an upgrade from 2.2.0 → 2.7.7 had to change the spring configuration of a pagination interaction to achieve almost same transition. Earlier on 2.2.0

transition={{
          x: { type: "spring", stiffness: 300, damping: 200 },
          opacity: { duration: 0.5 },
 }}

After upgrade to 2.7.7 stiffness doubled, damping halved.

transition={{
          x: { type: "spring", stiffness: 600, damping: 100 },
          opacity: { duration: 0.5 },
}}
tinglof commented 3 years ago

Any update on this issue? I am having the same problem using "2.7.7", do I need to downgrade to 2.2.0 again? Since If I would redo all the animations and this would be fixed I would have to redo it again.

mattgperry commented 3 years ago

Again this was a bug with overdamped springs, which stiffness: 300, damping: 200 absolutely is. The only thing that might ever change from here on is little tweaks with determining when a spring stops.

tinglof commented 3 years ago

Sorry I think I wasn't descriptive enough, I am having the same problem as the person who opened the issue. Upgrading from 1.X to 2.7.7 changed the default animation of spring types, as in I haven't passed in any stiffness or damping. So its not overdamped springs but rather the default one. I had to change all default springs to tweens to get it working smoothly. Any thoughts on this? Let me know if you need more data about it.

Edit: When trying to reproduce it I can't in a sandbox so I am wrong. The thing that got my eyes open to it was closening behavior of an accordion I am using like in this forked example, https://codesandbox.io/s/framer-motion-accordion-forked-vqr2q?file=/src/Example.tsx

But I am having the same issue with 1.X versions so I guess this isn't related. Sorry.