Jump to content


How does Greensock perform better than other solutions for animation?

Warning: Please note

This thread was started before GSAP 3 was released. Some information, especially the syntax, may be out of date for GSAP 3. Please see the GSAP 3 migration guide and release notes for more information about how to update the code to GSAP 3's syntax. 

Recommended Posts

Couple of days ago I discovered Greensock JS library. I am creating a web app with animations. So I decided to give it a try and I was surprised how smooth a movement can be.


My first attempt to implement animation was jQuery animate and it was far away from smooth movement. After that I found jQuery CSS transit library which was much better than jQuery animate method, but there was still some jitter while animation.


But Greensock beat all of them. I am getting very smooth movements.


I understand difference between jQuery animate where object is being moved little by little until destination is reached and CSS transition where library tells the browser to move the object to particular position and browser can optimize the movement because it knows object's origin and destination.


But how is this possible that Greensock has greater performance even over CSS transition? What is lying under it's performance?

Link to comment
Share on other sites

Shhhh...don't tell anybody...we discovered how to inject magical browser pixie dust that turns JavaScript into native machine code and offloads everything to the GPU to make quick work of animations. Kidding. The real answer is...well...somewhat complex. Here's a quick (but not complete) list of our techniques:

  1. Use highly optimized JavaScript across the board (this entails many things like using linked lists, local variables, quick lookup tables, inlining code, bitwise operators, leveraging prototypes instead of recreating functions/variables for each instance, etc.)
  2. Engineer the structure of the platform so that it lends itself very well to high-pressure situations, minimizing function calls and making sure things are gc-friendly. 
  3. Make updates in a single update loop that's driven by requestAnimationFrame, only falling back to setTimeout() if necessary.
  4. Cache some important values internally for faster updates.
  5. For CSS transforms, we calculate matrix values and construct either a matrix() or matrix3d() when there's any rotation or skewing because our tests showed that it was faster.

In short, we've spent a LOT of time focusing on performance. The platform has been in development for many years, and we've learned a lot. 


jQuery wasn't built for high-performance animation. It's an all-purpose utility library (and a very good one at that). GSAP, on the other hand, is highly-tuned animation engine that rendering-layer-agnostic, meaning you can use it to animate canvas stuff, DOM elements, WebGL, or almost anything that JavaScript can touch. The underlying JavaScript is made to be very fast, and very flexible. It scales well, plain-and-simple. 


I can't really speak to why CSS Animations/Transitions aren't as fast as you might expect, but I did write an article that addresses many of the myths out there, and performance is one of the biggies: 



I'm really glad to hear that you're noticing a difference with GSAP and it's serving you well. 


Happy tweening!

  • Like 8
Link to comment
Share on other sites

Thank you very much for answering. Now it makes more sense.


I enjoyed reading article you wrote!


And again, thank you for great product you have created!

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.