Super.īut did you know you can do that with JavaScript too? Setting a transform with a 3D characteristic (like translate3d() or matrix3d()) triggers the browser to create a GPU layer for that element. If you run out, things will drastically slow down.ĭeclaring your animations in CSS allows the browser to determine which elements should get GPU layers, and divvy them up accordingly. Side note: It’s not wise to give every element its own layer because GPUs have limited video memory. Instead of calculating every single pixel 60 times per second, it can save chunks of pixels (as layers) and just say “move that chunk 10 pixels over and 5 pixels down” (or whatever). The secret is to isolate the animated elements onto their own GPU layers because once a layer is created (as long as its native pixels don’t change), it’s trivial for the GPU to move those pixels around and composite them together. The GPU is highly optimized for tasks like moving pixels around and applying transform matrices and opacity, so modern browsers try to offload those tasks from the CPU to the GPU. Sounds yummy, right? Let’s break it down into two parts: GPU involvement The most frequently cited reason for using CSS for animation is “hardware acceleration”. So part of the reason JavaScript animation got a bad reputation is what I call the “jQuery factor”. The newer GSAP is also JavaScript-based but it’s literally up to 20x faster than jQuery. Most comparisons on the web pit CSS animations against jQuery since it is so pervasive (as if “JavaScript” and “jQuery” were synonymous) but jQuery is widely known to be quite slow in terms of animation performance. In my opinion, this is a glaring weakness in CSS but if you only do simpler animations that animate the entire transform state at any given time, this won’t be an issue for you. See the Pen Independent Transforms by GreenSock ( on CodePen For example, what if you want to animate “rotation” and “scale” independently, with different timings and eases? Maybe an element is continuously pulsing (oscillating scale) and you’d like to rotate it on rollover.
In CSS, they’re all crammed into one “transform” property, making them impossible to animate in a truly distinct way on a single element. Lack of independent scale/rotation/position controlĪnimating the scale, rotation, and position of an element is incredibly common. This article is meant to raise awareness about some of the more significant shortcomings of CSS-based animation so that you can avoid the headaches I encountered, and make a more informed decision about when to use JS and when to use CSS for animation. I didn’t get far, though, before I started uncovering a bunch of major problems that nobody was talking about. But is it?Īs someone who’s fascinated (bordering on obsessed, actually) with animation and performance, I eagerly jumped on the CSS bandwagon. JavaScript-based animation was treated as if it was antiquated and “dirty”. The darling of the industry for years now, CSS Animations have been talked about endlessly at conferences where phrases like “hardware accelerated” and “mobile-friendly” tickle the ears of the audience. The most widely-acclaimed solution was CSS Animations (and Transitions). Browsers matured and started offering solutions. They needed better tools for complex sequencing and top-notch performance.
Flash faded away and talented animators pressed HTML5 to do things it had never done before.
As interactive projects got more aggressive and mobile devices burst onto the scene, performance became increasingly important. Once upon a time, most developers used jQuery to animate things in the browser. Jack does a lot of work with animations in the browser and has discovered that the generic opinion that “CSS is faster” just isn’t true. The following is a guest post by Jack Doyle, author of the GreenSock Animation Platform (GSAP).
0 kommentar(er)
