Jittery/glitchy Animations in Firefox on Mac

[Ben Carey]

I have read various posts on here, some old, and some more recent, about animations being glitchy in Firefox. I have done my absolute best to obtain as much information as I can prior to posting this, in addition to creating the attached Codepen.

For some reason, I cannot get my animation to play smoothly in Firefox. To keep things simple, this is all the information I have (and have learned/tried):

• Issue only occurs in Firefox on Mac OS (smooth as silk in Firefox on Windows)
• Not my graphics card as a) it is a top spec 2019 Macbook Pro, and b) my designer has the same issue on his Mac
• I have tried the rotation fix
• I have tried force3D
• I have tried using low res images
• The more effects that I add, the worse it gets i.e. autoAlpha, Rotation, filter etc...

Additional information:

• I am using GSAP 2.1.3 as haven't had the time to upgrade (after I post this, I will attempt to create the same animation with the latest version in a separate codepen)
• It does seem as if there is a minor memory leak of some sort in either GSAP or Firefox because my fan goes mad when I have the codepen tab open and on screen
• I have wondered whether it is to do with the retina display as I had a similar issue with my fan in the past with this plugin that was caused by the retina display

Can anyone suggest what may be causing this?

 

See the Pen XWJoMWG by sinemacula (@sinemacula) on CodePen

[Ben Carey]

I have now created this in GSAP v3 and can confirm the issue still persists. See here:

 

See the Pen dyPwRqb by sinemacula (@sinemacula) on CodePen

[Shaun Gorneau]

Looking at this in Firefox 72.0.1, I really don't see any remarkable glitch or jank (that I don't also see in Safari or Chrome, that is).

 

Although, using string percentage values for the x/y properties could be contributing to that. Try using xPercent and yPercent as they take numeric values.

 

See the Pen KKwbqOR by sgorneau (@sgorneau) on CodePen

[Ben Carey]

Hi Shaun,

 

Thank you for your prompt response.

 

I assume you are using a retina display as well? I plugged my Mac into my monitor and whilst it isn't perfect, it seems to be better...

 

Funnily enough, using numeric values with xPercent and yPercent was the one thing that I thought of doing but I didn't actually try. I will try this now and see if it makes a difference.

[Ben Carey]

@Shaun Gorneau - I can confirm that the issue still persists when I use xPercent and yPercent. See here: 

See the Pen OJPrjXj by sinemacula (@sinemacula) on CodePen

 

I can also confirm that the animation is much less glitchy when I test it on an attached monitor which indicates the issue is related to retina displays.

[Shaun Gorneau]

25 minutes ago, Ben Carey said:

I have now created this in GSAP v3 and can confirm the issue still persists.

 

A few notes on GSAP 3 syntax. Duration is now a property within the vars object ... and a timeline can have default property values!  Because all of your tweens have a 1 second duration set, rather than set them on each tween, you can set them in the defaults. The same is true for rotation and ease! Of course, where ever you would like some other value, you would just include those on the tween. Have a look here,

 

See the Pen OJPrjVg?editors=1010 by sgorneau (@sgorneau) on CodePen

 

[Shaun Gorneau]

8 minutes ago, Ben Carey said:

I assume you are using a retina display as well? I plugged my Mac into my monitor and whilst it isn't perfect, it seems to be better...

 

I'm not on a retina display ... an older 2015 iMac  

[Ben Carey]

5 minutes ago, Shaun Gorneau said:

 

A few notes on GSAP 3 syntax. Duration is now a property within the vars object ... and a timeline can have default property values!  Because all of your tweens have a 1 second duration set, rather than set them on each tween, you can set them in the defaults. The same is true for rotation and ease! Of course, where ever you would like some other value, you would just include those on the tween. Have a look here,

Ah, brilliant!!! Thank you. You are probably wondering why I am not using fromTo as well, this is only because I thought that might be causing the issue when I first started debugging. I will changing to fromTo when it comes to publishing.

 

7 minutes ago, Shaun Gorneau said:

 

I'm not on a retina display ... an older 2015 iMac  

In that case, I am 99% sure this issue is caused by retina displays. This is further supported by the fact that it performs better when I plug my Mac into my external monitor (not retina).

 

Can you think of anything I can do to improve this?

[GreenSock]

Typically in cases like this, it has absolutely nothing to do with GSAP - I'd guess that 99.9% of the load is the browser rendering graphics. That's especially true on retina displays (a LOT more pixels for the browser to render). The filter is a big problem too. Various browsers have different techniques for rasterizing those, so my guess is that Firefox's is just...not fast.  

 

Have you tried REMOVING the will-change: transform, opacity and setting force3D:false? I know that sounds counter-intuitive and it may not help at all, but I'm trying to think like the browser and usually what will-change and force3D do is force the browser to layerize the image (shove it to the GPU) but if you also have a drop-shadow filter on it, perhaps every time it moves to a new position, it actually has to go BACK to the CPU, calculate all those pixels, then layerize it again, so there's a ton of traffic going back and forth. Totally a guess. 

 

Another thing I learned a while back is that certain browsers have limits on pixel dimensions and you take a BIG performance hit if you exceed a certain size. For example, imagine that memory-wise it works in blobs of pixels that must be less than 1000x1000 (I'm making that up), so if your image is 1100x1100 suddenly it has to break that into 4 blobs and patch them together, quadrupling the work. I noticed you've got some very large images - I'd recommend trying to see if busting those apart into smaller pieces helps at all. 

 

I definitely recommend ditching that drop-shadow filter. You could probably embed that in the image instead. WAY cheaper performance-wise. 

 

Another tip: minimize the number of pixels that change on the screen. Imagine drawing a bounding box around anything that changes (including off-screen portions) - the bigger that box, the more work you're forcing the browser to do rendering-wise. Keep that as small as possible. And don't think that if something is off-screen that the browser ignores it. That's often not the case. 

 

I hope that helps nudge you in the right direction. Let us know what you find as you try different things. The combination of retina displays (biggest factor due to exponentially more pixels to push around), plus the drop-shadow filter, plus the very large bounding box around changing pixels...and you're just asking a lot of the browser rendering-wise. Again, totally unrelated to GSAP.