Jump to content
Search Community

Laggy animations

monixm test
Moderator Tag

Recommended Posts

Hello GSAP Community! I created some animations on my page: https://www.monixm.com/ and I noticed that they are lagging a bit. I am using opacity(alpha)to hide and show content and I read somewhere that by increasing the opacity  to 0.1, the lagging is gone but then the effect doesn't look great...would you have any other advice? Thanks! 

See the Pen by (@) on CodePen

  • Like 1
Link to comment
Share on other sites

Hi @monixm and Welcome to the GreenSock Forum!

 

Just some additional info we need to better help you:

  • What browser and browser version are you seeing this on?
  • What OS and OS version are you seeing this on?

Some things you could do is to maybe add a slight rotation: 0.01 to your tween, and or also using autoAlpha instead of opacity for better performance.

 

autoAlpha is part of the CSSPlugin:

 

https://greensock.com/docs/v3/GSAP/CorePlugins/CSSPlugin#autoAlpha

  • autoAlpha
    Identical to opacity except that when the value hits 0 the visibility property will be set to hidden in order to improve browser rendering performance and prevent clicks/interactivity on the target. When the value is anything other than 0, visibility will be set to inherit. It is not set to visible in order to honor inheritance (imagine the parent element is hidden - setting the child to visible explicitly would cause it to appear when that’s probably not what was intended). And for convenience, if the element’s visibility is initially set to hidden and opacity is 1, it will assume opacity should also start at 0. This makes it simple to start things out on your page as invisible (set your CSS visibility: hidden) and then fade them in whenever you want.
  1. //fade out and set visibility:hidden
    gsap.to(element, {duration: 2, autoAlpha: 0});
    
    //in 2 seconds, fade back in with visibility:visible
    gsap.to(element, {duration: 2, autoAlpha: 1, delay: 2});

     

Also to better help you and please setup a limited codepen demo example so we can test your code live. Since trying to debug your code from your website will be really hard without your isolating the GSAP issue.

 

 

Happy Tweening! :)

  • Like 3
Link to comment
Share on other sites

I've ended up using TweenMax for now... All the animations with scale or rotate transform applied to divs with background-image are noticeably laggy with the release of new gsap 3, it was not the case with TweenMax or TweenLite however. This happening on chrome, firefox and edge.

Link to comment
Share on other sites

45 minutes ago, PaulB said:

I've ended up using TweenMax for now... All the animations with scale or rotate transform applied to divs with background-image are noticeably laggy with the release of new gsap 3, it was not the case with TweenMax or TweenLite however. This happening on chrome, firefox and edge.

 

Welcome to the forum @PaulB

 

It would be helpful if you could provide a simple example instance of your claims via a codepen. This would allow staff to evaluate these claims and assist in providing you some helpful feedback. If issues exist as you've stated then I’m sure @GreenSock would like to see an example so he can address things.

  • Like 2
Link to comment
Share on other sites

@PaulB yes, I definitely want to see a reduced test case if at all possible because GSAP 3 should not be noticeably slower than GSAP 2 and I'm very curious to see your use case. Do you have a reduced test case that shows v2 and the same thing with v3 that we can compare? I wonder if the perceived difference actually has nothing to do with GSAP but only a change in the way certain browsers render things. I remember a while back Chrome suddenly changed how it rendered 3D transforms (at least on the Mac) and it made a HUGE performance difference but nothing changed in GSAP. 

  • Like 4
Link to comment
Share on other sites

@Shrug ¯\_(ツ)_/¯ @GreenSock @Jonathan

 

Hi, have some cors issues on codepen at the moment, sorry...

 

Ive created non editable previews here, two examples, just rotation transform animation used.

 

Testing platform is windows 10 and latest versions of chrome, firefox and edge.

On android both previews works fine however...

 

TweenLite preview (smooth one):
/// Link removed

gsap v3 preview (laggy one):
/// Link removed

Hope this helps.

  • Thanks 1
Link to comment
Share on other sites

Can anyone reproduce the reported "lagginess"? I can't. I've tried several browsers. Everything is perfectly smooth.

 

@PaulB is there a secret to getting it to lag? 

 

It's super difficult to diagnose a live project where we can't tweak anything. Codepens are much better. Not sure why you're dealing with cors issues there. 

 

Does it make any difference if you set force3D: true or force3D: false? Just curious. 

Link to comment
Share on other sites

There is no secret, just very noticeable animation frame rate drop on windows 10 in all browsers, tried "force3D" - doesn't work. Try to swipe or click buttons.

 

It is very strange because on laptop and android phone there is no issues... Maybe some specific hardware/PC issue...

 

gsap v3 (laggy):

See the Pen QWwJBqq by Breiva (@Breiva) on CodePen

 

TweenLite (smooth):

See the Pen Powxxab by Breiva (@Breiva) on CodePen

 

Thanks.

Link to comment
Share on other sites

9 minutes ago, ZachSaucier said:

On my Mac there are no issues as well.

Just realized probably it could be some hardware issue, I have xeon on regular motherboard, maybe some memory issue or smth else but it is not the case if everywhere else it is working, thanks guys.

Link to comment
Share on other sites

22 minutes ago, ZachSaucier said:

If you can hone in on exactly what is causing the issues and whether or not it's directly related to GSAP we'd really appreciate your effort and input. We understand that if it's not worth figuring out the cause to you because it'd take too much time that's alright.

I'll try to check this and that.

Link to comment
Share on other sites

Yeah, I'm very curious to hear about what might be causing the difference. The only thing I notice is that v2 uses matrix() and matrix3d() whereas v3 uses translate()/translate3d() + rotate() but that really shouldn't cause performance issues. GSAP 2 did a bunch of calculations in the JS layer to build that matrix3d(), but v3 skips all those and lets the browser do it natively. Plus the newer way allows us to accommodate other units, like vw, em, etc. I suppose there's a chance that the way the browser interacts with your video card driver is somehow optimized more for matrix()/matrix3d() data but that still sounds weird to me. Theoretically the browser should be even faster at building that matrix data behind the scenes than letting GSAP do it in the JS layer. But I'm no expert at how every browser does things under the hood. 

  • Like 1
Link to comment
Share on other sites

17 hours ago, PaulB said:

Just realized probably it could be some hardware issue, I have xeon on regular motherboard, maybe some memory issue or smth else but it is not the case if everywhere else it is working, thanks guys.

  • What GPU graphics card do you use on your Xeon PC?

I have a Xeon PC at home and can check later on today to see if i still see it. Keep in mind that on my home xeon PC i dont use Nvidea GPU but a AMD Radeon GPU. I did not see it laggy on my non xeon pc that had Nvideo GPU.

 

  • Like 1
Link to comment
Share on other sites

Hi, I have some updates.

 

Switching from matrices and processor type most probably not the case here as appeared.

 

The key is that I have gaming monitor which is set to 100Hz. When I switch back to 60Hz issue is gone. 

 

That being said, when I do requestAnimationFrame, I get 100 fps to feed in versus 60fps on 60Hz monitors. In other words I need more animation frames to go from point A to point B in one second. 

 

And probably gsap v3 ticker is locked to 60 fps maybe? 
Because when I set CSS transition property on animated div as transition: transform 0.1s linear, I get these gaps between frames filled with browser additional frames and animation becomes smooth on 100Hz!

Link to comment
Share on other sites

GSAP is based on requestAnimationFrame which is completely controlled by the browser. It strikes me as a bit odd that CSS transitions would run at a totally different refresh rate than everything else; you'd think that the browser should repaint at a consistent rate regardless (unless the JS thread is super busy when the separate transforms/opacity CSS thread is ready to update in which case it'd just skip the JS-based updates) but I'm not a browser engineer so I couldn't tell you how or why they do stuff under the hood. 

 

What's the most baffling to me, though, is that you said the GSAP v2 was smooth whereas GSAP v3 wasn't, but they're BOTH based on exactly the same mechanism (requestAnimationFrame). Were your eyes just playing tricks on you? Maybe you tested v2 when you were in 60hz mode, and you tested v3 in 100hz?

Link to comment
Share on other sites

4 hours ago, GreenSock said:

GSAP is based on requestAnimationFrame which is completely controlled by the browser. It strikes me as a bit odd that CSS transitions would run at a totally different refresh rate than everything else; you'd think that the browser should repaint at a consistent rate regardless (unless the JS thread is super busy when the separate transforms/opacity CSS thread is ready to update in which case it'd just skip the JS-based updates) but I'm not a browser engineer so I couldn't tell you how or why they do stuff under the hood. 

 

What's the most baffling to me, though, is that you said the GSAP v2 was smooth whereas GSAP v3 wasn't, but they're BOTH based on exactly the same mechanism (requestAnimationFrame). Were your eyes just playing tricks on you? Maybe you tested v2 when you were in 60hz mode, and you tested v3 in 100hz?

 

Hey, no, both tested on 100Hz and TweenLite is smooth whereas gsap v3 is lagging... You can try and test it out on some higher refresh rate monitor?

Link to comment
Share on other sites

5 hours ago, PaulB said:

Im curios in this case browser performs css transitions, or gsap is counting animation steps(frames) amount needed to perform and feeds in calculated transform values each period of time based on timing/easing?

GSAP is time resolution-independent, meaning it calculates the values based on the exact time of the update. It does NOT assume that you'll run at 60fps and pre-calculate values or anything like that. With some animation engines, if your framerate slows down to 30fps, for example, when it was assuming you'd run at 60fps, all your animations end up taking twice as long (bad). Not GSAP. Even if your frame rate drops substantially (or increases), it'll always render the values where they're supposed to be based on the overall time, not FPS. It also has some advanced features like lag smoothing that are automatically enabled to heal from CPU spikes. And the timing mechanisms are identical in v2 and v3. 

 

Does that answer your questions? 

 

I'm really struggling to understand why you noticed a difference in v2 vs v3 but nobody else can and the only significant difference (which really shouldn't be significant at all in terms of performance) is that v2 calculates the matrix()/matrix3d() instead of using values like translate()/translate3d() + rotate(), etc. I'd actually think v3 would be a bit faster in that regard. 

  • Like 1
  • Thanks 1
Link to comment
Share on other sites

  • 3 weeks later...
On 1/21/2020 at 10:57 PM, GreenSock said:

GSAP is time resolution-independent, meaning it calculates the values based on the exact time of the update. It does NOT assume that you'll run at 60fps and pre-calculate values or anything like that. With some animation engines, if your framerate slows down to 30fps, for example, when it was assuming you'd run at 60fps, all your animations end up taking twice as long (bad). Not GSAP. Even if your frame rate drops substantially (or increases), it'll always render the values where they're supposed to be based on the overall time, not FPS. It also has some advanced features like lag smoothing that are automatically enabled to heal from CPU spikes. And the timing mechanisms are identical in v2 and v3. 

 

Does that answer your questions? 

 

I'm really struggling to understand why you noticed a difference in v2 vs v3 but nobody else can and the only significant difference (which really shouldn't be significant at all in terms of performance) is that v2 calculates the matrix()/matrix3d() instead of using values like translate()/translate3d() + rotate(), etc. I'd actually think v3 would be a bit faster in that regard. 

 

I've experienced this issue after migrating to v3 from v2 also. After some digging I found the difference was that GSAP is now defaulting to 60 fps if a manual override isn't provided: https://github.com/greensock/GSAP/blob/master/src/gsap-core.js#L843

 

So on a screen with a refresh rate above 60hz GSAP tries to throttle the rAF loop resulting in janky animation.

 

My workaround has been to set the fps to -1 like so: gsap.ticker.fps(-1)  

 

Would it be possible for GSAP to allow an option to not limit the fps? Since >60hz screens are becoming more and more popular, particularly in mobiles, I think this is important.

Link to comment
Share on other sites

11 minutes ago, ashthornton said:

I've experienced this issue after migrating to v3 from v2 also. After some digging I found the difference was that GSAP is now defaulting to 60 fps if a manual override isn't provided: https://github.com/greensock/GSAP/blob/master/src/gsap-core.js#L843

I'm pretty sure that's not true...

  1. GSAP is built on top of requestAnimationFrame by default and most browsers max out at dispatching those events 60 times per second. It's not a limitation that GSAP imposes. Most people can't even perceive more than 60fps. I'd hardly call 60fps "janky" :) 
  2. GSAP v2 used exactly the same logic - I'm not sure why you think v2 was somehow better.  

Can you provide a reduced test case that shows v2 performing better than v3? I'm super curious to see that. It'd help a LOT in terms of troubleshooting. 

 

17 minutes ago, ashthornton said:

My workaround has been to set the fps to -1 like so: gsap.ticker.fps(-1)  

I'm not sure why that'd help - are you saying that makes your animations look much smoother? And did you try setting it to something like 120 or 144? Again, a reduced test case that shows this improving things would be awesome. 

  • Like 1
Link to comment
Share on other sites

23 minutes ago, GreenSock said:

GSAP is built on top of requestAnimationFrame by default and most browsers max out at dispatching those events 60 times per second.

 

I think Safari is the only browser that is capped to 60fps.

https://bugs.webkit.org/show_bug.cgi?id=173434

https://github.com/whatwg/meta/issues/158

 

 

25 minutes ago, GreenSock said:

Most people can't even perceive more than 60fps.

 

I can, but the difference isn't as noticeable as the difference between like 30 and 60.

 

Link to comment
Share on other sites

1 hour ago, GreenSock said:
  1. GSAP is built on top of requestAnimationFrame by default and most browsers max out at dispatching those events 60 times per second. It's not a limitation that GSAP imposes. Most people can't even perceive more than 60fps. I'd hardly call 60fps "janky" :) 

 

60fps definitely isn't janky and even on a 60hz+ refresh rate screen it looks smooth, i.e. when watching 60fps videos/gaming but it seems that GSAP's attempt to throttle to a maximum of 60 even though the browser might be able to go higher definitely causes a stutter that you wouldn't normally see.

 

1 hour ago, GreenSock said:
  1.  GSAP v2 used exactly the same logic - I'm not sure why you think v2 was somehow better.  

 

Not exactly, as far as I can see:

 

Here in v2 https://github.com/greensock/GSAP/blob/2.1.3/src/uncompressed/TweenMax.js#L6479

 

If _fps hasn't been set, which it isn't by default, it allows the next tick to be dispatched as soon as browser RAF is fired - bypassing any check of a negative overlap that might be caused by _gap

 

Here in v3 https://github.com/greensock/GSAP/blob/master/src/gsap-core.js#L857

 

That _fps check is removed so it relies solely on whether there is a negative overlap or not. Which does happen when RAF has fired more than once in 1/60 seconds.

 

On a 60+hz display if you log out overlap you'll see negative values which will cause the conditional to be skipped and the internal event to not be dispatched.

 

So setting _fps to -1 forces a positive overlap every time and we get an un-throttled loop.

 

Hopefully that all makes sense and I've read the code right. If it does then you can see why setting fps to 120 or 144 would also remove the throttle but the reason I won't do that is because there are already higher refresh rate screens out there and I don't want to limit those.

 

I can set up a reduced demo if you'd like but it'd just be a square translating across the screen or something then enabling and disabling gsap.ticker.fps(-1) on v3, then the same on v2 without any special config.

 

Of course you need a screen with a refresh rate higher than 60hz to see any of this!

Edited by ashthornton
typo
Link to comment
Share on other sites

I certainly don't mind setting it to a default of 240, as the fps() only acts as a cap anyway. That should give it plenty of room :) 

 

Can you confirm that setting fps() to 240 makes things smoother on your end? Or better yet, just try the beta of the upcoming release: 

https://s3-us-west-2.amazonaws.com/s.cdpn.io/16327/gsap-latest-beta.min.js

  • Like 1
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...