Both are technologies for creating graphics in html5 context, how is SVG different from canvas and which one should I use?
So with a few click within google, I found this quite comprehensive article on MSDN. I will hereby put down a simple summary of my own understanding.
We will start by talking about the two different modes these two technologies respectively adopt.
1. Retained mode vs Immediate mode
These are two different modes adopted by graphics APIs. To put it simple, retained mode can be seen as having memory between frames. Let's say you put a circle on the first frame. The API enables you to refer to this same circle and update it in the coming frames. On the contrary, immediate mode does not remember what you've done in the previous frame. Each frame, the scene is drawn from scratch.
[I also stole these nice graphs from MDSN.]
2. Finally... canvas vs SVG, what really is the difference?
Well...basically this question is entirely explained by the previous section：canvas uses immediate mode, while SVG uses retained mode, that is all. I am not kidding. Every other argument can be derived from this point.
SVG is designed in retained model, then how does it refer to shapes that have been drawn? Well, SVG is XML based. Shapes are referred to as elements, in DOM.
'SVG is essentially to graphics what HTML is to text',
according to MDSN's introduction on SVG.
(What can I say, MDSN also provides best tutorials with great mottos that should be printed on posters.)
If you are familiar with DOM, SVG will be an piece of extra cake for you. After all, just like HTML, it is essentially designed to work with DOM. The mindset is the same. You create an element(say, a circle), you add attributes to it, manipulate it, update or delete it. Also like HTML, it can be styled with CSS, and uses SMIL for animation.
On the other hand, canvas is really just...canvas, a fixed-size pixel map. It is called low-level graphics API - you manipulate at the pixel level. Granted, most browser APIs provides functions that enables you to draw primitive types easily, but keeps this principle in mind. Each time you need an update on the graph, you need to tell the program to redraw everything pixel by pixel.
3. Let's be practical... what can I do with each?
I will again conveniently stole some image from MDSN.
It's always useful to keep the performance factor in mind. To summarize, Canvas do better with large number of objects or/and small size of screen. SVG do better with large size of screen and small number of objects. This conclusion is predictable, as you know, SVG maintains references to objects, at a cost. While canvas redraws every pixel, also at a cost.
Now, forward to practical scenarios. Look at this graph below, which could work as a nice summary. Static images and high fidelity documents actually are talking about the same thing: the V in SVG, actually stands for vector, and S, is for scalable. Basically, you can zoom it or enlarge it to your heart's content and the image will still be crystal sharp, yeah!
On the other side, canvas is good for complex scenes, mathematical animations, real-time data, video manipulation and all other stuff that is best worked at PIXEL-LEVEL, as we've emphasized many times.
And another two scenarios talked in the article but not on the graph, which might as well be the most used scenarios - data representation, and games.
It is easy to see why in most cases data representation works better with SVG. SVG is worked on a object level, API takes care of all the referencing to objects, which you can directly bind to your data.
On the contrary, canvas does not by nature have this object referencing, thus the problem. Let's say we are drawing a bar chart. Now my data is update from 15 to 20 and I need to make my bar from 15px long to 20px long. With SVG, it is quite easy since you can directly refer to that rectangle that is your bar and modify the attribute accordingly. But you don't have this luxury with canvas. 'Increase the bar length!' You ask. 'Bar? What bar are you talking about?' Canvas replies. It won't work unless you write code to take care of the referencing yourself.
But, as we said, most cases. If you want a real-time representation where large changes occurs to a large number of objects every frame, you might as well do it pixel by pixel, that is, with canvas.
Last, games. If you have done game development, this is a no brainer. Most visuals in game development are handled in a frame by frame, pixel by pixel way, especially if you want smacking visual effects. But this is also to say, if we are doing web-based casual games with limited visual effects and limited number of objects, SVG might also be sufficient.
4. You said something about P5 and D3 in the title?
Yes, I did... Ok, I have to admit first that I don't know much about both, merely just took a peek in each. Also, P5 is more that a visualization library, granted. But P5 is good for some cool visual effects, check on this channel on youtube. From the quick peek, P5 uses canvas and has its main function, draw(), as a looping function that executes at a fixed time interval to redraw the whole canvas. Remind you of update() in Unity, isn't it?
On the other hand, D3.js, or data driven documents as its full name, is indeed a data visualization library in JS utilizing SVG. It is a good example of the difference between canvas and SVG. Also, I am looking forward to dive into the source codes of the two and to see how each is designed, well... as soon as I've got some free time. In that case, I might update my findings here.
