Greensock (GSAP) is much less smooth/more jerky compared to css animations in this simple example. Is there a way to improve it?

Question

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 compare 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 common 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 compare 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 compared 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
    });
});

Answer 1

This is a more of an apples-to-apples comparison (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 comparing 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.com/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 complex 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.com/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.