Snap.svg vs svg.js

[Thijs Koerselman]

Hi,

I've been working with Snap for about a two weeks because it seemed to be the obvious choice when doing svg for modern browsers. But yesterday I had a closer look Svg.js, and reading through the docs I get the impression that it has more features and I like the object oriented structure. Maybe that's also because the docs seem more readable and complete then those of Snap.svg which mainly just look pretty imo.

So before I start porting my code I was wondering; does any of you have experience with SVG.js and what are the reasons you're using Snap instead?

I am using this for realtime animation (like a game engine) so performance is important, but I can't find a proper comparison nor benchmarks. Svg.js is developed by someone who claims to be a visual artist and only part-time nerd, which worries me slightly. Snap.svg is, I suspect, developed by a full-time nerd backed by Adobe, which in theory looks more promising ;)

[Ian]

I haven't really use svg.js, but keep a bit of an eye on it on SO.

I personally would code in whichever feels the most intuitive for what you want to achieve. I like Snaps simplicity, but appreciate thats not for everyones solution.

When I looked, I didn't see a lot between them really, not in terms of anything that couldn't be coded around quick and easily, and I think it probably fairly easy to transition between them if necessary.

I think Snap has some added bits with Matrices that I've found useful. svg.js a few other functions in other areas.

As you're main focus seems to be game related, I would say that both I would imagine both would be similar performance, as they will likely use a loop and repositioning during the interval. One thing to be wary of is that SVG in itself isn't necessarily that great if you want to move a lot of objects, especially if you have transforms like scale/rotate on them. You may be better looking at Canvas.

Both afaik are maintained by people who have other projects they focus on, so I wouldn't make a decision on that basis. Toss a coin and decide, but you may want to do a few tests in SVG in general first for your audience (especially if mobile), just to see if SVG in itself can perform as you would like.

[Thijs Koerselman]

Thanks for your advice. I think I will give Snap a little more time, since I've started on it anyway. Also I found what I assume to be your sketches here http://svg.dabbles.info/. That helped me to understand some concepts better. Thanks for sharing!

The only thing I miss now is relative move but that is easy to add myself.

I want SVG because of the looks and flexibility. I don't know how many objects I'll be moving yet so I'm curious to find the limits. Things need to be tight, but I don't think canvas is an option for me. I will try to write a proper test soon.

[Thijs Koerselman]

The creator of svg.js pointed me to this benchmark, saying it can easily outperform Snap:

http://jsperf.com/raphael-vs-snapsvg-attr/3

It shows really significant performance differences in favour of svg.js. What I don't understand is that Raphael outperforms Snap, so I think I need to do some more real world tests in order to get a better picture. But if performance differences are this big in other areas too than it's worth investigating.

[Ian]

You don't see a lot moving on the screen do you :) ?

I think if you need raw speed, then you need to get as minimal as possible, and svg.js I would imagine faster at setting stuff, and no library even faster. If you really want to get speed and talking about gaming, you probably want canvas.

However, as mentioned, nothing moves on the screen. I don't know jsperf, so I'm quite likely talking cobblers, but I'm guessing this isn't timing svg draws, just setting attributes in reality so relatively insignificant. The thing that takes the time with SVG is the actual drawing, transformations, painting etc. Browsers don't draw SVG on a frame by frame basis, with a nice wait, they try and shortcut, and there is no way to wait until one part is finished.

To try and highlight what I mean, if you look at a loop on a random draw http://jsfiddle.net/vy2vycn4/ You won't see it move apart from once (feel free to increase loop to 1000). 

The thing that really takes the time in a different way, is coding. My main advice would be not to get bogged down in testing stuff before you've written anything, you will never finish it. Get writing with sensible logic and functions, and you will find that if you need you can drop in svg.js, snap, canvas, whatever.

[Thijs Koerselman]

True, I should focus on coding first. I have a habit of getting too much into detail too early in the development stage :)

Then again performance will largely dictate what I can do, because it's not going to be a game and the visual complexity will be limited by what the browser can render at a fast framerate. I specifically want the tight anti-aliased 2d look of vector graphics. I have never seen a 'pixel' rendering library match that look.

You're probably right in that the test doesn't really tell you much, other maybe than that there could be big differences in the efficiency of javascript implementations. If most of the processing is in the rendering of the shapes, then the browser's svg engine might be the bottleneck and not the javascript that drives it. That's what I meant with doing some real world tests. I'm planning to animate objects in realtime and see if I can notice big differences in framerates.

I'll report back when I have some real results :)

[Ian]

I did have a play ages back with SVG and trying to do some vector based animation in a typical game loop to see how performance was. The main things I would say to watch out for with SVG is the amount of objects in the DOM that are being moved about, the amount of fill in an object, transformations (especially heavier calculation ones like rotation) and filters/gradients (I found this especially when trying to do things like glow effects on lines, like geometry wars etc). They add add a toll onto the performance, and things like accessing an attribute you can tweak later if you need those further optimisations.

There may even be combinations of canvas and svg that could be interesting, but could be a bit fiddly, and not really tried that much.