Jump to content
GreenSock

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

Performance on Large & Complex SVG

Recommended Posts

Hi everyone!

I'm planning on making a Christmas project which would require many elements being animated on a fullscreen illustration. So imagine 100-200+ little animations moving repeatedly on a fullscreen page, along with music running.
You could think of Google's SantaTracker as an example - Website and Github.

 

I dabbled with canvas for a bit, but animating proved to be a lot more complex than with simple SVG and Greensock. and attempted to bring in SVGs in Paper.JS as well, to merge the gap between SVGs and canvas, but I kept running into difficulty exporting SVG paths to be animated. --> If you have experience with SVG in Paper.JS, I'd love to hear about your experiences!

I didn't really like canvas to start with anyway... (I'm just not familiar with it enough).

 

So I'm thinking of sticking to pure inline SVG and Greensock animation, since I like the simplicity yet high quality vector aspect of them. The issue is I have kept hearing of SVG performance issues due to the DOM (where canvas performs much better in comparison).

 

I have done tests with heavier illustrations imported from Illustrator, where 100+ elements are animated and looped; other than using a lot CPU, performance on desktops/laptops seemed fine (macbooks and such); there was a bit of lag on mobile devices, but subtle enough to be able to get away with it. I tried a Nexus 6P which is probably a good phone though...

 

I ran tests on several websites (with Google's PageSpeed's tool notably). It scored between 50-60%, which isn't ideal. 

Since I am new to development, and know little about performance testing, I wanted to ask the Greensock community your thoughts on what I should maybe look out for and for best practices. Or if you have any advice on how to go about this.

I have though of importing static components as PNGs or JPEGs instead of SVG, would that help with the performance or would it do the opposite? Think background elements for example.

 

I have thought of using the <use> tag to duplicate existing SVG code to lighten inline SVG-load. But I have read that doing that actually is detrimental to performance. Has anyone had that experience?
 

Looking forward to hearing your thoughts.

Thanks!!

  • Like 1
Link to comment
Share on other sites

I was so happy with my first, half SVG banner. But suddenly I realized: it is LAGGING! Why? Why is it laggin when my full surface is only 970x250 and I am moving only a few vector elements?! S..t! This one month of coding of my SVG DOM exporter was a wasted time?

I was exprerimenting a bit and turned out I can't force the GPU to accelerate these element. When I did that with CSS, the animation is just stopped working.
Then I saw a guy who put all his <path>s into <div><svg>*</svg></div>s and feed them into the GPU. Hell no!

The main problem is: there is no bitmap caching on SVG elemens like in EaselJS's canvas.

I think SVG gonna be good for animations in next 15 Years in the era of Quantum computing.

But pleease contradict me!

  • Like 1
Link to comment
Share on other sites

This is a very interesting issue I think. I can't contribute because my knowledge is rather short in this matter. I hope the experts here will contribute on this subject.

Link to comment
Share on other sites

Yep, most browsers don't GPU-accelerate SVG, probably because of the resolution-independent nature of it (meaning pixels aren't locked-in; they can be fabricated based on many factors). 

 

If you're going to have a bunch of animations happening simultaneously and many pixels changing on each tick, I suspect you'll get better performance with canvas (especially a library like PixiJS since it can leverage WebGL). Yes, it is indeed more complex and can be trickier to make "responsive" size-wise and it's harder to debug/inspect, but if performance is your primary concern I'd be willing to bet you'll see better frame rates with canvas/PixiJS. 

 

Then again, SVG is getting better all the time and I'm obviously a big fan. Many projects don't really require the extreme performance that a canvas solution delivers. SVG is perfectly adequate (in fact, better in my opinion) if you're not being aggressive animation-wise. 

 

Happy tweening!

  • Like 2
Link to comment
Share on other sites

Thanks Carl,

 

Anyone knows IF and if so WHEN  the main browser builders (Chrome, Edge, Firefox, Opera) are planning to implement SVG->GPU hardware animation?

Link to comment
Share on other sites

Maybe in SVG 2.0 since that will support CSS 3D transforms. But until then your better off just wrapping your SVG with a div tag and animate that for better performance when needed.

 

So basically as for now SVG elements will always trigger re-layout and re-painting. But if you wrap the SVG with a <div> tag, and then you are not limited by the limitations of how modern browsers handle SVG. And then with the <div> tags the GPU can kick in and not have to re-layout and re-paint if CSS 3D transforms and there supported properties are used.

 

:)

  • Like 2
Link to comment
Share on other sites

I'll touch on performance later, but I wanted to find out how you were creating animations in Paper.js? You don't need to export anything. Paper has all the tools you need for working with SVG. It's pretty much a JavaScript version of Adobe Illustrator, and actually started out as an extension to allow you to draw inside Illustrator with JavaScript.

 

There's a bunch of different ways to animate paths in Paper with GSAP. Just as an example, here's how you can use Paper's .interpolate() method with the MorphSVGPlugin.

 

See the Pen 46c3f44f94aeff75021e4b49dd3a1a73?editors=0010 by osublake (@osublake) on CodePen

 

I can go into detail later, but I just wanted to show you that you can animate directly inside of Paper with GSAP.

  • Like 3
Link to comment
Share on other sites

I'll touch on performance later, but I wanted to find out how you were creating animations in Paper.js? You don't need to export anything. Paper has all the tools you need for working with SVG. It's pretty much a JavaScript version of Adobe Illustrator, and actually started out as an extension to allow you to draw inside Illustrator with JavaScript.

 

There's a bunch of different ways to animate paths in Paper with GSAP. Just as an example, here's how you can use Paper's .interpolate() method with the MorphSVGPlugin.

 

See the Pen 46c3f44f94aeff75021e4b49dd3a1a73?editors=0010 by osublake (@osublake) on CodePen

 

I can go into detail later, but I just wanted to show you that you can animate directly inside of Paper with GSAP.

First off thanks everyone for contributing answers! 

 

To Blake, I was having issues importing SVGs into PaperJS and then selecting paths within the imported SVG to animate. I thought that by avoiding having all the SVG elements in the HTML, and rather having PaperJS import them from SVG files would save on performance. But once imported, I was having difficulty extracting the paths to animate later on. It would work for HTML embedded SVGs though.

Have you had experience with this case in particular?

 

But thanks for the Codepen! I'll take a closer look at the code.

 

I have since been looking into PixiJS. 

 

Link to comment
Share on other sites

In Paper.js, I usually create new path/objects instead of trying to import an SVG directly.

 

But if performance is what you're after, Pixi.js will deliver.

 

Click to add bees....

See the Pen ORJjGj by osublake (@osublake) on CodePen

 

And you can do some crazy stuff like bending images...

See the Pen 3ccd225b73a7fb9aeffafbe8afac75f0 by osublake (@osublake) on CodePen

  • Like 4
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.
×