Jump to content
GreenSock

Search In
  • More options...
Find results that contain...
Find results in...
marcamos

Scaling a *huge* SVG by a *large* number = blurring / stuttering

Recommended Posts

Hello! A new project has brought me to GSAP and I'm starting to wrap my head around what's possible, how to do things, etc. Please forgive me as I fumble my way through this…

 

Rather unsurprisingly, I've stumbled into a wall with regard to the first animation this project requires, which can be described as scaling a huge svg by a large number … but perhaps it's better to link straight to a demo page. Forgive me for not using CodePen—they have a file-size limit and this demo exceeds it:

 

https://jsfiddle.net/163eys6b/7/

 

Give your browser a little extra time to process that page; like I said, the SVG is huge.

 

The project calls for a big map of (almost) the entire world which starts zoomed all the way in to Amsterdam, which then slowly zooms out all of the way, from scale:1600 to scale:1. In the above JS Fiddle, you'll notice that it does what it should do, but it does it with a stutter (I'm using the latest version of Chrome stable as I type this, version 47.0.2526.111).

 

I can remove the stutter by removing force3D:falsebut that results in a very blurry experience about 5 seconds after the zoom-out animation begins.

 

Am I doing this right? Or, is this SVG + scale combination just too much for the browser to handle comfortably?

 

Thanks for your time!

Link to post
Share on other sites

Hello marcamos, and welcome to the GreenSock forum!

 

There are a couple things you can do, but keep in mind that this is not a limitation of GSAP, its just your trying to animate a large SVG, and it would be the same for any large DOM element, like images, etc.. using CSS animations, keyframes and transitions.

 

First you can make the size of your SVG be its full size on load, and use the GSAP set() method to scale down to the starting position you need it at, below scale factor of 1. And then you would just scale up to a scale factor of 1, meaning at 100%. then you could use force3D:true or force3D: "auto" which is default. Webkit and some firefox builds have a anti-alias bug in which elements when scaled over a scale factor of 1 can get blurry due to how it forces your element onto the GPU.  Making like a snapshot of an element that gets put on a  rendering layer. And that can cause really bad blurriness, due to this anti-alias browser bug. Again this is not a GSAP bug but a browser bug.

 

Secondly you could add a slight rotation:0.01 to your tween along with the scale, this helps take away some choppiness. But keep in mind your moving a large DOM element or elements slowly. Which in all browsers can cause Jank due to this being animated with the CPU, instead of the GPU (hardware acceleration), when force3D is set to false. But even with force3D true, you can see jank due to how large your element is.

 

Also in your case you are using position relative with your transform, which is fine, but position absolute works better since it takes your element out of the flow of the document so it doesn't trigger layout for your surrounding elements, whereas position relative does take your element out of the flow of the document, but could trigger layout since it is dependent on the parent its relative to.

 

You might want to run your SVG in a online SVG optimizing tool so you can clean up the SVG code as much as possible, since it has to animate such a large DOM element.

 

SVG online optimizer: https://jakearchibald.github.io/svgomg/

 

Thirdly, another way is to start with a smaller SVG file and use the SVG viewbox attribute to have it scale your SVG natively for your initial SVG size. Since SVG's are vector and can scale nicely even when a small SVG file or markup is used. So you can dramatically decrease the size of your SVG, and allow the browser to scale it natively to its initial size using the SVG tags viewbox attribute (minus your width and height attributes), for the initial size of your SVG markup.

 

https://developer.mozilla.org/en-US/docs/Web/SVG/Attribute/viewBox

 

i hope this helps! Please let us know if you have any more questions :)

  • Like 5
Link to post
Share on other sites

Thank you Diaco and Jonathan. I'm going to read through that other thread, and try all of the tips recommended above. I'll report back later today, I'm sure.

Link to post
Share on other sites

A lot of great advice above. Definitely read the thread Diaco linked too as I believe the biggest bottleneck is the rendering (outside of GSAP's control). You have 43,000 lines of SVG "instructions" that the browser needs to calculate 60 times per second. 

 

Another idea is to remove detail from the svg once it reaches a certain size. For instance, once the elements of the town get so small that they are indiscernible, perhaps you can remove them or replace them with artwork with much less fidelity. Modifying the svg while its scaling may very well hinder performance but its an interesting technique to consider or experiment with.

 

Sarah Drasner explains how to make responsive svgs that change their content based on viewport size here: 

 

https://www.smashingmagazine.com/2015/03/different-ways-to-use-svg-sprites-in-animation/

 

Its not the same as what you are doing but the general concepts may still apply.

  • Like 4
Link to post
Share on other sites

Thanks again for all of these tips; I've implemented as many of them as I know how, and the results are no better. I think the client and I need to rethink this project a bit; perhaps chunk-up the one SVG into many smaller ones that can be added/removed smoothly … or something along those lines.

Link to post
Share on other sites

If it doesn't need to be interactive, I wonder if you might get better results animating in After Effects and saving out a video?  

 

That 3+ MB SVG file is crazy!

  • Like 1
Link to post
Share on other sites

Update! After speaking with the client, we're splitting up the gigantic SVG into multiple smaller SVGs that will have far less data and can be strung together with little transitions between them. I've been working on this adjustment for a few days now and it's much better. Thanks, again, for everybody's help!

  • Like 2
Link to post
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.

×