animating css transform stutters on first execution

[overdub60]

I've created a scale animation with tweenmax which stutters upon executing the first time. Every time after that, it renders fine. This problem is most visible in Chrome on a Mac.

 

See my Codepen here. Please run it directly on code pen instead of this embedded version, otherwise the problem won't be visible:

 

See the Pen vRgYYQ by overdub60 (@overdub60) on CodePen

 

You have to reload the page to see the stuttering. Click on the content and the scale animation runs.

 

When I do the same with regular CSS transitions instead of TweenMax, it looks smoother to me. I've created a codepen for that as well:

See the Pen zWNmyK by overdub60 (@overdub60) on CodePen

 

Does anyone have an idea why that is and can possibly offer a solution?

 

Before anyone says I should just use the CSS transition then, it won't work, because I need to sync up with other TweenMax tweens.

 

Thanks!

 

[Sahil]

I notice couple of problems,

 

1. You are using 3 year old version of TweenMax.

2. You are using will-change everywhere, which can be counter productive because it puts additional work load on GPU memory if I am not mistaken.

3. You were using Tween but updating your scale using onUpdate which is unnecessary as you can directly tween your element.

 

See if following demos help,

 

See the Pen BrWNbv?editors=0010 by Sahil89 (@Sahil89) on CodePen

 

See the Pen pLejjJ?editors=1010 by Sahil89 (@Sahil89) on CodePen

 

[overdub60]

Thank you @Sahil for your help. Unfortunately, the problem remains. Do you see what I mean, even in your demos?

[Carl]

It appears to me that using TweenMax to handle the scaling of the object removes that little glitch on initial run.

See the Pen YaZBMr?editors=0010 by GreenSock (@GreenSock) on CodePen

Does that work better for you?

 

 

 

 

 

[Jonathan]

Hello @overdub60 and Welcome to the GreenSock Forum!

 

I could not see the transform stutter using @Carl's codepen fork of your codepen in either Chrome or Firefox. In your codepen I did see a slight hesitation though on start.

 

You should really look into using will-change very sparingly. It seems you are using it on properties that it wont even work on, like height.

 

The CSS will-change property should only be used on CSS properties that regularly and constantly change, and need to be kept optimized.

 

Only the following keyword values should be used with the CSS will-change property:

• will-change: auto;
• will-change: scroll-position;
• will-change: contents;
• will-change: transform; 
• will-change: opacity;

But you should really only use will-change for the CSS transform and opacity properties. Since they will be the only ones that can take advantage of getting a new stacking context and put on a new rendering layer.

 

See Jack's ( @GreenSock ) article regarding this on CSS Tricks:

 

https://css-tricks.com/myth-busting-css-animations-vs-javascript/

 

Also keep in mind that will-change has some buggy intermittent behavior cross browser, especially in webkit based browsers like Chrome, Safari, Opera, and MS Edge. You can see the following article in regards to that.

 

https://greensock.com/will-change

 

I noticed in the browser inspector that when your element animates at first, that scale is not rendering using transform: matrix3d() or scale3d() on the element. This can be achieved by adding a slight rotation:0.01 on the GSAP tween to allow matrix3d(). That will create a new stacking context and makes your animation smoother. But again keep in mind that using will-change on parent and also children elements can give you worse performance and not better performance, thus negating the use of will-change.

 

Just my two cents, Happy Tweening

[OSUblake]

 

9 hours ago, Jonathan said:

Only the following keyword values should be used with the CSS will-change property:

• will-change: auto;
• will-change: scroll-position;
• will-change: contents;
• will-change: transform; 
• will-change: opacity;

 

Don't forget about filters. will-change can be a huge optimization for filters that do convolution like blur and drop shadow.

 

 

And I don't know what's going on with these demos, but it's creating some weird glitches on my computer. Look at how the code is glitching, and starts spazzing out. 

 

 

 

 

 

[Jonathan]

I excluded filters since I have seen really bad repainting of nested children bug in Chrome. Where in one Chrome version will-change will render will-change: filter correctly. Then the next release of Chrome breaks that behavior. And then guess what?  The next version of Chrome corrects the bad repainting behavior. Then rinse and repeat.. fun stuff

 

@OSUblake if you report it to codepen they will look into that wiggity wiggity whack.

[overdub60]

Thanks for all the feedback! Unfortunately, none of the suggestions improve the tween smoothness for me. I removed the will-change properties completely since they neither improve nor degrade performance for me in this case. Also, @Carl, I don't see any difference in your example compared to mine. I also changed the TweenMax version to the most recent one. Again, no change. I also added the slight rotation suggested by @Jonathan, didn't help either. Weird!

 

Here's my latest demo:

 

See the Pen zWwazQ by overdub60 (@overdub60) on CodePen

 

[Jonathan]

@overdub60 can you plesse provide

 

- What browser you seeing this on?

 

- What browser version you seeing this on?

 

Since this seems very specific what your seeing. Thanks

[overdub60]

@Jonathan I see this most on Chrome 65.0.3325.181, macOS High Sierra, 2015 Mac Book Pro. I see it on Safari 11.0.3 as well though. It's also visible on a co-worker's computer, also the latest Chrome. So it's not just my machine. And from what I gather from the responses here, people have seen the glitch on their machines as well right?

[Jonathan]

Hi again, thanks..

 

@overdub60 That explains it.. chrome and safari on macOS will render differently then chrome on windows. And out of all webkit version chrome and safari on macOS or iOS have their own little quirks. I didn't see a glitch stutter on chrome windows 10, just a slight hesitation on start, but the animation was still smooth in @Carl's codepen.

 

Just trouble shooting here since i dont have access to macOS...

 

Try to check and make sure your image is completely loaded in the DOM and window before animating it. It using DOMContentLoaded and the window load event handler check. You can also see that in dev tools timeline and inspector on it timing if your animation is starting before the window and or DOM is ready.

 

You can also try testing your codepen in debug mode since by default codepen displays in an iframe which can cause other render issues. Whereas codepen debug mode does not. You can always test that by changing the word /pen/ to /debug/ in your codepen URL.

 

When you inspect your codepen ... Does it show on the inline style of the animated element in dev tools inspector transform: scale() or transform: matrix() or transform: matric3d() ? This will make sure that your element is animating on a new rendering layer and that it uses the GPU (hardware acceleration) instead of the CPU.

 

Thanks for any additional info.

[overdub60]

@Jonathan Thank you!! Once I go out of /pen/ and into /debug/ everything renders smoothly! So it seems it's just a codepen issue! Also, I wasn't aware that maxtrix() performs better than scale(). Does that apply to scale3d() as well? I thought once we enable 3D, we always get hardware acceleration?

[Jonathan]

@overdub60 glad you got it sorted out. Codepen sometimes will get all crazy with rendering making you go insane when its codepen that is the issue.

 

Sometime there are browser bugs or browser constipation that will not honor when you tell it to force3D: true. Again this isn't a GSAP bug, but just how the various browser bugs affect each browser when using CSS transforms. Its like the wild west, so some times you have to get a posse together and reign in these longhorn browser bugs.

 

As a rule of thumb to get around these browser bugs or criminal activity.. I sometimes add a slight rotation: 0.01 when using scale, x or y, which can also give you matrix3d() for hardware acceleration. Now this doesn't mean you always have to force hardware acceleration. Sometimes the browser will animate 2D perfectly without hardware acceleration. But there are times when hardware acceleration can have the opposite effect and cause stutter or jank (lost frames) due to browser bugs. So it's always best to test and inspect, then test and inspect.

 

Other properties that can trigger matrix3d() are z, skewY, and rotationY.

 

Happy Tweening!

[overdub60]

thank you @Jonathan!

[PointC]

2 hours ago, Jonathan said:

Codepen sometimes will get all crazy with rendering making you go insane when its codepen that is the issue.

 

The issue with my CodePen demo is my CodePen demo? Is that like when we type 'Google' into Google and rip a hole in the space-time continuum?