Jump to content
GreenSock

Search In
  • More options...
Find results that contain...
Find results in...
HypoLast

GSAP Crashes in Firefox on Mac

Recommended Posts

A while ago we built a website using GSAP, which can be seen here for reference: www.mikutech.com

 

We use TimelineMax and TweenMax to power all of the animations on the site. It recently came to our attention that the site sometimes crashes the browser, but only specifically on Firefox for Mac. We've had two separate Macbooks running different versions of Firefox crash on the site now. Chrome and Safari run the site fine, and all three run fine on Windows. I tossed together a sample using the same kind of transformations and similar amounts of animations in the the codepen link attached. It runs fine in all of my browsers on Windows but again, in Firefox on Mac, if you try to scroll around it freezes and eventually crashes.

 

The website is kind of old at this point and has an older version of GSAP on it, but we have a local version of the site with all the libraries updated which exhibits the same behavior. If we disable the animations the site is smooth, so it's definitely not any of the other scripts on the site causing the issue.

 

Any help or insight into how to avoid these crashes would be greatly appreciated.

See the Pen egpLJq by HypoLast (@HypoLast) on CodePen

Link to comment
Share on other sites

Hm, I'm not surprised that's crashing the browser - you're creating infinitely more and more elements and adding them to the DOM without ever removing them. Of course animating them adds to the load on the browser, but ultimately it's just a really dangerous thing to do (keep adding to the DOM). Eventually it requires too much memory and the browser just can't manage it all. 

 

[edit: it's not infinitely adding things to the DOM - only 60 things. Corrected below...]

 

That effect would be **MUCH** more efficient if you did it with canvas (and still animate it with GSAP of course). DOM nodes are just way more heavy and difficult for the browser to manage. Canvas is just a blob of pixels. 

 

In short, I'm pretty confident the problem is unrelated to GSAP. If you fix the way you're generating (and disposing of) the elements, that should resolve the problem. 

  • Like 3
Link to comment
Share on other sites

Hm, I'm not surprised that's crashing the browser - you're creating infinitely more and more elements and adding them to the DOM without ever removing them. Of course animating them adds to the load on the browser, but ultimately it's just a really dangerous thing to do (keep adding to the DOM). Eventually it requires too much memory and the browser just can't manage it all. 

 

That effect would be **MUCH** more efficient if you did it with canvas (and still animate it with GSAP of course). DOM nodes are just way more heavy and difficult for the browser to manage. Canvas is just a blob of pixels. 

 

In short, I'm pretty confident the problem is unrelated to GSAP. If you fix the way you're generating (and disposing of) the elements, that should resolve the problem. 

 

When you say we're adding infinitely more and more elements to the DOM do you mean in the codepen link or on the website? In codepen there are exactly 60 elements being created and added, they get recycled by having the animation repeat forever. I don't have the exact count for the website but we avoided dynamically creating elements exactly so that wouldn't be an issue, I can assure you it's finite.

 

If it were an infinite loop I would expect it to crash any browser but I can leave the codepen or our website open all day on any browser other than Firefox for Mac and it runs fine, but on Firefox on a Mac both crash almost instantly. On the website I tried shimming the TweenMax and TimelineMax methods to empty functions and then the site ran fine on Firefox for Mac. If it was an issue of an infinite loop in our code I would expect to see performance issues crop up at some point even with the shims.

 

I can see if I can reproduce the issue using GSAP with canvas as well. I don't have easy access to a Macbook though, so it may take me a couple days to have an example that I can verify reproduces the issue using canvas.

Link to comment
Share on other sites

Sorry about that - I rushed the response as I was prepping for a meeting that I need to run to. You're right, it's not infinitely adding stuff to the DOM. It is animating top/left instead of x/y, and that's definitely not good as top/left affect document flow (even though you've got position:absolute). Another odd thing that might be causing Firefox to choke (even though technically it shouldn't) is that you're animating both the scale AND the width. So since you've got this mix of transforms and flow-affecting stuff, it's very tough on the browser.

 

It's trying to GPU-accelerate things with transforms, and that means capturing the "texture" (like a screenshot of the element) and uploading that to the GPU, but then on every screen refresh you're altering the width which forces the browser to dump the old texture and re-capture the new one at the new width and upload it to the GPU, etc. 

 

I suspect you'd see a huge performance increase if you animated all transforms (x/y/scale) instead of the mix of top/left/scale/width.

  • Like 3
Link to comment
Share on other sites

No problem, I know what that's like.

 

Thanks for the thoughts, I'll try your suggestions when I get the chance and report back.

Link to comment
Share on other sites

Hello HypoLast,

 

Keep in mind that running in codepen will also be a bottleneck since codepen has a tendency to crash Firefox when using a loop. I have experienced this myself with simple for loops on Windows.

 

Also when testing in Firefox you might want to test in either safe mode and or private browsing mode. This way you can make sure that extensions and other addons do not affect the performance. Firefox is known to have a really bad memory leak. Firefox has a habit of leaving unneeded plugins Activated. Just a way to test if it still happens when they are Never Activated

 

Addons => Plugins

 

It will help you troubleshoot ;)

 

After a crash and you restart Firefox you should go to the URL about:crashes and copy the last 5 crashes id's and report to Mozilla

 

https://support.mozilla.org/en-US/kb/firefox-crashes-troubleshoot-prevent-and-get-help

 

Also keep in mind and make sure that all plugins are disabled or set to ask to activate. Based on what you describe your causing many expensive layout geometry changes to be triggered since your animating top and left which requires the browser to use the CPU intensively to recalculate the DOM on every render tick and every new element creation. Causing a lot of layout thrashing. Sometimes its better to create all the elements up front in a hidden state and then animate the elements. Instead of constantly adding new DOM elements into the DOM animating top and left on each loop iteration.

 

Please see CSS Triggers:

 

Does trigger layout geometry changes - top, left

 

https://csstriggers.com/left

https://csstriggers.com/top

 

Does not trigger layout geometry changes - transform

 

https://csstriggers.com/transform

 

:)

  • Like 3
Link to comment
Share on other sites

It seems like using x/y/scale has fixed the performance issue we we're experiencing. Thanks guys!

 

However, it doesn't seem like using x/y works with the Bezier plugin. You can actually see the difference in my codepen vs Carl's, in the one using left/right the boxes curve nicely across and down, in the one using x/y the boxes go straight on a downward angle, not respecting the curve. On the site this causes the particles to travel directly through a block of text that they're supposed to curve around. I did some Googling but wasn't able to figure out why this might be.

Link to comment
Share on other sites

I think the lack of curvature in the animation is just an illusion caused by the fact that there are only 2 points in your bezier, the type is "soft" and the divs are being scaled to a large size from their centers. I changed some values just to help illustrate that they are following a path: http://codepen.io/GreenSock/pen/EZKZmR?editors=0010

 

See what i mean?

  • Like 3
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.
×