I'm new to gsap so if I'm doing something horribly wrong then please correct me, but this is a pretty simple example. I'm just trying to pare performance of css animations to gsap animations in Firefox and Chrome, to decide which to use for an animation I may be working on in the future.

Based on examples that I've seen on various sites it looked like gsap was supposed to perform better in general and be less wonky with more options, but for this simple example that's not what I'm seeing at all, and I would think something like this would be something quite mon to both use cases of css and gsap animations.

I know about the Firefox issue referenced here, where you need to apply a rotation to animations or sub pixel rendering is not used, so I've applied the rotation in both the css animations as well as the gsap animations to try and fix the jerkiness in Firefox. That did help, but still when you pare the two animations in either Firefox or Chrome, the gsap example visibly lags. The two animations are not exactly moving at the same easing, but I think it's close enough that they can be pared properly.

Firefox gsap performance is still much worse than in Chrome, but Chrome gsap does still lag every few repeats or so, while in Chrome the css animations do not. It looks to me like Firefox css animation is about as good as Chrome gsap performance.

Here is the codepen so you can see for yourself, note that to see it properly you should open the link and expand your window, and it'll work best on a resolution of at least 1920x1080:

So am I doing something wrong? Are there more tricks to increase performance such as the Firefox rotation trick? Is this just something specific that greensock has problems doing? Any help or insight would be appreciated.

Thanks!

Relevant HTML, CSS, and JS:

HTML:

<div id="site-wrapper">
  <div class="css-animations">
    <div class="square">css</div>
    <div class="circle">css</div>
  </div>
  <div class="gsap-animations">
    <div class="gsap-square">gsap</div>
    <div class="gsap-circle">gsap</div>
  </div>
</div>

CSS:

@keyframes pulse {
    0%, 100% {
        transform: translate(100px, 0) rotate(0.01deg);
    }
    50% {
        transform: translate(1500px) rotate(0.01deg);
    }
}

@keyframes circle-pulse {
    0%, 100% {
        transform: translate(100px, 0) rotate(0.01deg);
    }
    50% {
        transform: translate(1500px) rotate(0.01deg);
    }
}

JS:

$( document ).ready(function() {
    var tl = new TimelineMax({
        repeat: -1
    });

    var tl2 = new TimelineMax({
        repeat: -1
    });
    var $square = $('.gsap-square');
    var $circle = $('.gsap-circle');

    tl.to($square, 1.5, {
        x: 1400,
        ease: Power1.easeOut,
        rotation:0.01
    })
    .to($square, 1.5, {
        x: 0,
        ease: Power1.easeOut,
        rotation:0.01
    });

    tl2.to($circle, 1.5, {
        x: 1400,
        ease: Power1.easeOut,
        rotation:0.01
    })
    .to($circle, 1.5, {
        x: 0,
        ease: Power1.easeOut,
        rotation:0.01
    });
});

I'm new to gsap so if I'm doing something horribly wrong then please correct me, but this is a pretty simple example. I'm just trying to pare performance of css animations to gsap animations in Firefox and Chrome, to decide which to use for an animation I may be working on in the future.

Based on examples that I've seen on various sites it looked like gsap was supposed to perform better in general and be less wonky with more options, but for this simple example that's not what I'm seeing at all, and I would think something like this would be something quite mon to both use cases of css and gsap animations.

I know about the Firefox issue referenced here, where you need to apply a rotation to animations or sub pixel rendering is not used, so I've applied the rotation in both the css animations as well as the gsap animations to try and fix the jerkiness in Firefox. That did help, but still when you pare the two animations in either Firefox or Chrome, the gsap example visibly lags. The two animations are not exactly moving at the same easing, but I think it's close enough that they can be pared properly.

Firefox gsap performance is still much worse than in Chrome, but Chrome gsap does still lag every few repeats or so, while in Chrome the css animations do not. It looks to me like Firefox css animation is about as good as Chrome gsap performance.

Here is the codepen so you can see for yourself, note that to see it properly you should open the link and expand your window, and it'll work best on a resolution of at least 1920x1080:

http://codepen.io/apodworny/pen/dpkEQg

So am I doing something wrong? Are there more tricks to increase performance such as the Firefox rotation trick? Is this just something specific that greensock has problems doing? Any help or insight would be appreciated.

Thanks!

Relevant HTML, CSS, and JS:

HTML:

<div id="site-wrapper">
  <div class="css-animations">
    <div class="square">css</div>
    <div class="circle">css</div>
  </div>
  <div class="gsap-animations">
    <div class="gsap-square">gsap</div>
    <div class="gsap-circle">gsap</div>
  </div>
</div>

CSS:

@keyframes pulse {
    0%, 100% {
        transform: translate(100px, 0) rotate(0.01deg);
    }
    50% {
        transform: translate(1500px) rotate(0.01deg);
    }
}

@keyframes circle-pulse {
    0%, 100% {
        transform: translate(100px, 0) rotate(0.01deg);
    }
    50% {
        transform: translate(1500px) rotate(0.01deg);
    }
}

JS:

$( document ).ready(function() {
    var tl = new TimelineMax({
        repeat: -1
    });

    var tl2 = new TimelineMax({
        repeat: -1
    });
    var $square = $('.gsap-square');
    var $circle = $('.gsap-circle');

    tl.to($square, 1.5, {
        x: 1400,
        ease: Power1.easeOut,
        rotation:0.01
    })
    .to($square, 1.5, {
        x: 0,
        ease: Power1.easeOut,
        rotation:0.01
    });

    tl2.to($circle, 1.5, {
        x: 1400,
        ease: Power1.easeOut,
        rotation:0.01
    })
    .to($circle, 1.5, {
        x: 0,
        ease: Power1.easeOut,
        rotation:0.01
    });
});

• javascript
• css
• animation
• gsap

• If you can get away with CSS transitions/animations, then go ahead and use them. They will almost always be faster and smoother than GSAP. The power of GSAP isn't its performance (although it is generally pretty good) but instead the huge amount of control it gives you over your animations. GSAP can do things that CSS simply can not. – jered Commented Oct 4, 2016 at 22:19
• JCD is correct. I usually use vanilla JavaScript to animate anything plex at 60fps on the web; however, for the jQuery programmer, I can remend using Velocity.js as it is optimised to produce smoother animations. – AM Douglas Commented Oct 4, 2016 at 23:57
• @amdouglas an admin on the greensock forums at the following link says "I have yet to see a case where VelocityJS is faster.", do you think he is biased? Also, are there any ways to make css animations perform better if javascript animations are always going to be slower? in firefox, css animations still aren't perfect. source: greensock./forums/topic/… – Alex Podworny Commented Oct 5, 2016 at 5:25
• Fair enough, I didn't say GSAP is slower, that was the guy above me. I just suggested trying an alternative. CSS animations can be quickened by forcing hardware acceleration. This is typically done by forcing an element into a new layer, i.e. by doing something like this: element { transform: translateZ(0); backface-visibility: hidden; } or in modern browsers: element { will-change: transform; } will-change @ caniuse. – AM Douglas Commented Oct 5, 2016 at 12:33

1 Answer 1

This is a more of an apples-to-apples parison (kinda): http://codepen.io/anon/pen/BLJGwK?editors=0110

On my system, I couldn't notice any difference in terms of smoothness, but I realize results may vary by system, graphics card, etc.

And your GSAP code could be quite a bit more concise (here's the meat:)

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

tl.to('.gsap-square, .gsap-circle', 1.5, {
  x: 1500,
  ease: "quad"
}).to('.gsap-square, .gsap-circle', 1.5, {
  x:100,
  ease:"quad"
});

Please keep in mind:

• You're paring the best possible scenario for CSS, and worst possible scenario for JS because if you only animate transforms (or opacity), most modern browsers delegate that to a different thread. There are other consequences to that, however. See http://greensock./css-performance for a video explanation. In many other cases, GSAP was actually faster than CSS.
• If you add even one other property to your animation (doesn't matter what, just something besides transforms or opacity), you lose that separate thread boost in Firefox (the entire thing, including transforms, goes back to the main thread...at least that's my understanding and it has to do with the synchronization issue mentioned in the article above).
• GSAP does automatically GPU-accelerate things for you via JS.
• You might want to try adding will-change:transform to the elements you're animating.

The real benefit of GSAP over CSS (and other libraries), according to most people I talk to, has to do with:

• Workflow. Changes and experimentation are much easier for even moderately plex animations. Total control of every aspect. Way more easing options. Hook up scrubbers, seek(), reverse(), timeScale(), etc.
• Compatibility. GSAP works around a ton of browser bugs and inconsistencies that'll bite you if you try animating with CSS.
• Capabilities. GSAP can do far, far more than CSS. Won't bore you with a list here, but it's extensive. Partial list is at http://greensock./why-gsap/

And yeah, GSAP is hyper optimized for performance. It's pretty widely seen as the gold standard in that regard. I'm not aware of anything faster, though CSS animations of transforms do have an advantage in this one scenario. But frankly I doubt it'd even be noticeable in most real-world scenarios. I always encourage folks to do their own tests.

Sorry if that sounded like a sales pitch. Didn't mean it that way - I just wanted to set the context properly. Sometimes I see people get hyper-focused on one particular scenario or use case and they miss some very important factors that might be worth considering.