Jump to content

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

Recommended Posts

Hi all,


like the topic already mentions do I have a problem with stuttering animations inside my TimelineMax animation and it would be really great, if somebody of you could help me.

I'm currently developing a system for our company in which images and videos of our work can be uploaded/selected with the help of a CMS. These media should be animated afterwards, so that it looks like a dynamic generated showreel. So I used PHP to dynamically generate the JavaScript code and basically it works, but as you can probably see in the Codepen or in the demo, especially in Chrome the animations are stuttering a lot (depending on your computer/device).
I have to say that I'm new to Greensock and also not the most experienced developer, so I would appreciate every advice of you. Regarding my code I guess there's a lot of potential for optimization. Especially the way of adding the subtimelines to the maintimeline and calling the functions of the subtimeline is probably wrong. For example:

var mainTimeline = new TimelineMax({repeat:-1});


function websiteTimeline(website) {

    MorphSVGPlugin.convertToPath("circle, rect, ellipse, line, polygon, polyline");
    // Create sub timeline
    var timeline = new TimelineMax();

    // Add tweens to sub timeline

    function morphToPhone() {
        TweenMax.to("#bezel-macbook", 0.2, {morphSVG:"#bezel-phone"});
        TweenMax.to("#camera-macbook", 0.2, {morphSVG:"#camera-phone"});
        TweenMax.to("#screen-macbook", 0.2, {morphSVG:"#screen-phone"});
        TweenMax.to("#shape-macbook", 0.2, {morphSVG:"#lock-phone", css:{opacity:0}});
        TweenMax.to("#line-macbook", 0.2, {morphSVG:"#speaker-phone", css:{opacity:0}});
        TweenMax.to("#touchpad-macbook", 0.2, {morphSVG:"#lock-phone"});

I also already read about the performance differences between JavaScript and CSS, so my next step would be to use more pure CSS and less TweenMax animations, but I wanted first ask you guys, if you have some better advices for me. :-)

I hope anyone of you can help me.

Here again the links to my Codepen and demo...



Demo: http://mathis-krueper.de/captain/references/

Thanks in advance! :-)

See the Pen ZeQEzZ by mathis-krueper (@mathis-krueper) on CodePen

Link to comment
Share on other sites

Hello mathis, and welcome to the GreenSock Forum!

  • Are you seeing this in Chrome on Windows PC or on Apple Mac?

The reason i ask is because i don't see it stutter on Windows 7 or Windows 10 in Chrome latest build.



Link to comment
Share on other sites

Hi Jonathan,

thank you for your quick answer!

I'm currently developing and testing it on an iMac from late 2012 and also noticed that it runs much more fluent in Firefox. But I already tested it yesterday on my Laptop with Windows 10 and there I had also a lot of stuttering in Chrome. So I don't know your computer but I guess you have more cpu or gpu power than me. ;-)
The main problem is, that the system should run on a Mac mini, which has also big problems with the animations (in Firefox too). So if you have any advices for me how I could improve the code, I would be really glad. :-)

If you need further information or anything else, please let me know.

Edit: I also forgot to mention, that Chrome should be run in Fullscreen mode and then the stuttering is getting worse.

Link to comment
Share on other sites

There are small things you could do to possible help with Chrome and the stutter train.


If it were me i would make sure you are defining perspective property for any transformed children's parent. And using backface-visibility: hidden on the faces of your cube. They help to make sure the browser renders 3d properly, especially when rotation is involved.


Most importantly:


I notice that you are animating position offsets like top and left. You should never animate top and left, but instead animate x and y. This way you are animating transforms which can animate on a sub-pixel level and use the GPU to animate for a smoother animation. Unlike position offsets top and left animate using the CPU, animate on pixel level, are not animated using hardware acceleration, and when animated cause layout to be calculated on each frame. Also i see your animating width and height which like position offsets left and top do not animate on a sub-pixel level and will cause layout to be calculated  on each frame causing jank (lost frames or stuttering)


Animating the following CSS properties will ensure BAD performance:

Animating the CSS transform property using x, y, and z will ensure GOOD performance:

Also you should use GSAP special property called autoAlpha instead of opacity for better performance.


See the GSAP CSSPlugin Docs:



  • 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.
    //fade out and set visibility:hidden
    TweenLite.to(element, 2, {autoAlpha:0});
    //in 2 seconds, fade back in with visibility:visible
    TweenLite.to(element, 2, {autoAlpha:1, delay:2});

Also read this great article by GreenSock's own Jack Doyle, on why animating transforms x and y are better than animating position offsets like top and left for silky smoothness.





  • Like 2
Link to comment
Share on other sites

Hi Jonathan,


Thank you for your detailed answer!

I changed my code regarding your advices and in fact the animations were more fluent, but not as fluent I hoped. So I continued testing and I finally found the "wrongdoer". It was the CSS Blur filter for the background image which caused so much work for the cpu (or gpu I'm not quite sure). So now it runs like a charm, even on the Mac mini and in fullscreen mode.

I'm so sorry for wasting your time, but I really didn't expect that this filter can cause so much trouble. But thanks to you, my code is optimized now. :-)

So, thank you again for your help!

Link to comment
Share on other sites

Yep that would do it .. CSS filters are CPU hogs and require a lot for the browser to paint and render when not on its own composite layer. CSS Filters can use the GPU for better performance. But the rule of thumb is that same element needs some type of 3d transform to trigger that element on a new rendering composite layer to animate the CSS Filter with hardware acceleration (GPU).


So in short:

  • CSS filter() without a 3d transforms = uses the CPU
  • CSS filter() with a 3d transform = uses the GPU

But still CSS filters are very resource hogs, but do better when using the GPU.



  • 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.