Jump to content
Search Community

Optimizing scale performance on complex inline svg

gmbirdiv test
Moderator Tag

Recommended Posts

I'm somewhat new to web development in general so especially new to GSAP and am attempting to use it to zoom in (scale) and out on a somewhat complex inline svg. Have been poking around the forums about scaling svg and svg performance but can't really come to a conclusion on what the best way to go forward is so I was looking for a bit of advice before going any further. 


The codepen provided just has the different ways I've been attempting to zoom in on a specific part of the svg. In the codepen I have zooming in using css animation, gsap animation, gsap animation on a parent div, and lastly gsap animation using the viewbox instead of scale.  


I was jut wondering what the reason behind the performance differences where, mainly between css and using gsap when scaling.  Currently I'm getting much better performance using css but would like to transition away from css animations as its makes animation timing more difficult.  


Besides the codepen, I have the beginning of my current attempt up at https://gmanb94.github.io/portfolio/ which is currently using the CSS route. 


Right now, the zoom animations I'm focusing on are working ok on chrome with slight stutter every now and again, badly on firefox, but very well on safari for whatever reason. 


I also understand that I probably need to do more to optimize/prepare the svg I'm using (as you can assume new to dealing with the svg format as well) but so far my attempts which have included optimizing the svg online and splitting out the the parts I want to animate and putting the rest into an image tag haven't shown a notable increase in performance. If going the pixijs route is recommended I'd understand as I've seen that come up quite a bit on this topic but would rather make sure there ins't something far simpler I'm missing, especially since I'm getting the performance I'm looking for on safari. 


Any advice in what direction to head in would be greatly appreciated. 

See the Pen YzVWOzo by gmbirdiv (@gmbirdiv) on CodePen

Link to comment
Share on other sites

Welcome to the forums (and web development...and GSAP), @gmbirdiv


Performance optimization is a very, very deep topic. It would take many hours to try to explain the ins and outs, but here are a few quick thoughts: 

  1. The bottleneck is almost always graphics rendering. The actual changing of the underlying numeric values (which is what GSAP does) is dirt cheap compared to dynamically fabricating all those pixels on each tick. Like...the pixel calculations (totally unrelated to GSAP) accounts for well over 95% of the load in most cases, so focus your attention there. 
  2. The main reason CSS may be performing better for you in this particular scenario is because GSAP has to do some extra work under the hood in order to ensure cross-browser perfection (technically it's building a transform matrix() and baking in the transform-origin values on the fly). There's a massive tradeoff with using CSS - you get quite a few browser bugs, quirks, and different behaviors in various browsers, especially with transforms. Trust me - you're gonna get really frustrated if you go the pure CSS route. Ask anyone with experience. You might get it to look good in Safari and then open Firefox where everything falls apart. And then if you need to animate scale and position independently and maybe with different eases and timings, you're hosed. It's just very limiting. 
  3. The key is to minimize the graphics rendering work. SVG is notoriously hard on the CPU because it is forced to calculate all those vectors constantly as you scale. If those pixels are just sitting there or you're only animating a small portion of them, it'd be fine. But when you scale an entire complex set of artwork like you're doing, think of how many pixels must get fabricated. And it has to do all the ones off-screen too! So if you zoom up to 300% and you've got a ton of pixels spilling outside the viewport, it's just really tough on the CPU. Completely unrelated to GSAP or CSS.
  4. Optimizing your SVG probably won't help a whole lot. Sure, it might reduce the file size a bit but ultimately if it has a bunch of vectors that are taking up a very large portion of the screen, it'll be a lot of work. 
  5. If you rasterize your artwork (think of it like a screen capture, or saving your SVG as a PNG), it's MUCH easier for the browser to just shove around a set of pixels rather than fabricating them on every tick from vectors. One tradeoff can be pixelization if you scale UP, but you can solve that by saving your artwork at the scaled-up size natively. In other words, if you're scaling from 100% to 300%, you should save your artwork at 300% nice and sharp, and then scale THAT from 33% to 100% to get that same effect. 
  6. PixiJS could be a very useful tool for something like this but the concepts are the same. Ultimately you'd want to rasterize the artwork which could be on a <canvas> with PixiJS and scale that. It's more hassle production-wise, though.
  7. One trick you can try is to wrap your SVG in a <div>, set will-change: transform on that, and animate the scale of that <div> because most browsers can essentially rasterize the artwork and GPU accelerate regular DOM nodes (but most can't do that for SVG children). Worth a shot before you invest a bunch of time going the PixiJS route.  

I hope that helps!

  • Like 4
  • Thanks 1
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.
  • Create New...