Jump to content


Performance of Animating Opacity

Moderator Tag

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

I am attempting to animate opacities of several elements and experiencing some performance issues.


Some preface...


I'm using Snap.svg and have ported the RaphaelPlugin for Snap in my fork of GreenSock (https://github.com/anthonygreco/GreenSock-JS/blob/master/src/uncompressed/plugins/SnapPlugin.js) so generally speaking if anyone has experience with the RaphaelPlugin, any info you may have on the matter should be at least mostly relevant, though anyone with experience with GSAP may have just as valuable input.


Now for the problem at hand. I have roughly 1500 different path elements on a page in which no more than 400+/- of them are animated at any one point and only animating their opacity via staggerTo shows the other simple animations choppy. The most interesting part is that the 400 or so path elements don't seem to be choppy, but the simple animation is. My first question is simple; I may have more afterward but for now.... are there any idiosyncrasies to staggerTo that I may not be aware of from a performance perspective? Eventually, I'll probably rebuild what I've done in a JSFiddle to get more specific circumstances available for assistance, but right now I'm more interested in the overall larger picture and any optimization guidelines anyone may have.

Link to comment
Share on other sites

I'm not quite sure I understand your question. There's nothing particularly noteworthy performance-wise about staggerTo(), no. Feel free to look at the source - it just loop through the array and creates a tween for each with the proper delay. No biggie. 


This sounds more like it's possibly a browser rendering issue. From the Flash days, I know that it can be very challenging for GPUs/CPUs to animate vectors rather than raster images. Perhaps the opacity change also kicks them into a different GPU mode, like forcing them onto their own layers (that can be a good thing, or sometimes bad). Also, you must keep in mind the redraw rect that things are generating - the pixels that are "dirty" and need to be redrawn on each refresh. That area should be kept to a minimum. If you're moving a hundreds of vector objects and animating their opacity, it may just be too much strain on the processor rendering-wise (the actual GSAP code execution may only account for a tiny percentage of the overall CPU load). Tough to know without seeing a specific codepen example or something. 


Good luck!

Link to comment
Share on other sites

Upon further debugging I've discovered that this seems to be more of an issue of concurrency. For instance, I've removed all of the elements in place with only one rectangle in one svg node that has an endless tween like so:

TweenMax.to(rect, 3, {snap: {rotation: 360}, ease: Linear.easeNone, repeat: -1, repeatDelay: 0});

As soon as any other animation is triggered (i.e. a hover event of a DOM element that just fades in/out a div on over/out) the rotation animation jerks for a millisecond and the hover animation is choppy from beginning to end.


I'm gonna set up a JSFiddle shortly with an example, but thought I'd let you know my new finding since I'd imagine this is something you've seen before, I'm just wondering if it's something that can be mitigated. Fiddle to come...

Link to comment
Share on other sites

Thanks for clearing up staggerTo Jack. That's what I thought after checking the source, but wanted to be certain I wasn't looking right over something. --- It's been a long week.....


So, for a JSFiddle: http://jsfiddle.net/anthonygreco/Kpe67/


Now this is weird... In my actual project I just created ONE rect that was rotating and was experiencing the performance issue, but in JSFiddle I have to up the number of elements to see performance decrease. Which actually makes perfect sense to me and may well be eluding to the fact that I may have other things going on in my logic that aren't immediately apparent that are adding to this issue.


Either way the performance issue does become noticeable as you add more elements. Just swap the commented out line for the howMany variable to see what I'm referring to. So my question of concurrent animations still stands. Is this something that's simply a limitation of hardware/browsers in general? Is there any type of "caching" or other ideas I could possibly do to help mitigate the issue?


I know there was a link I saw (that I can't find now :P) that demonstrated the power of GSAP over other animation libs (i.e. jQuery's animate()) and remember that I upped the limits of the particles being emitted and was blown away at how well GSAP performed so I feel like there's a way to fix this.


I'm about to swap out the tween.to()'s for timelines to see if that has any weight on the matter.


I welcome any other thoughts or ideas on the matter.

Link to comment
Share on other sites

Crack open Dev Tools and record a timeline and you'll see that the big performance drain is all Snap - it has nothing to do with GSAP which can crank through those 500 tweens without breaking a sweat. There a TON of timers being set up by Snap (weird). So in summary, the sucky performance is completely Snap's fault  :shock:

  • Like 2
Link to comment
Share on other sites

So I reached out to the Snap community as well and I've found what's supposedly a "caching mechanism" of sorts that is now commented out (https://github.com/adobe-webplatform/Snap.svg/blob/master/dist/snap.svg.js#L4430) in my Snap source (which turns out, the number of "Timer Fired"s is equal to the number of elements in the scene and as many as 50 times in a second... agreed a TON) and I still see the issue: http://jsfiddle.net/anthonygreco/Kpe67/ so now I'm really lost as to what is causing this.  :?


I am thinking more and more that I need to move away from SVG for this project, but want to as if there is any chance there's anything else I should look at benchmarking first?

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.