HTML5 Canvas versus SVG for interactive charts and graphical models

Submitted by Jack on Tue, 28/02/2012 - 14:10

Some links and notes:

Toolkits and Frameworks

Tutorials and demos

Current conclusions

I should use Raphaël and one of its graphing add-ons.  I need to do more than just plot a standard line chart; I want lots of interaction.

Canvas is a lower level graphics API than SVG.  Canvas thinks in terms of individual pixels whilst SVG thinks in terms of vector objects.  Canvas is good for high performance 2D graphics like games; but SVG is good for applications which draw objects like boxes, lines etc.  My only slight concern about using SVG is that  I may run into performance issues if I want to build a full-screen waveform viewer.  Also,pre-Honeycomb Android doesn't support SVG (but does support Canvas).  But I don't care about pre-Honeycomb Android for my specific application.

tags:

  • Share/Save
  • Jack's blog

Comments

Matan (not verified)

Sat, 25/08/2012 - 12:22

I beg to slightly defer. It may seem it matters most how you would use SVG or Canvas (i.e. mainly what library or libraries you'd use for driving them). Directly working with SVG means crafting SVG paths yourself, or relying on a library that won't always satisfy your needs. Canvas has libraries driving it, which would draw objects for you just as using SVG would. Your code, or the library you use for driving Canvas, should, per my understanding, be able to remember objects and hence you would have the same level of object oriented approach as supplied by SVG. Using Canvas, you will not be bound to the specs of SVG in your abstractions. You will not have to produce SVG elements and mix css and code as you would in SVG. You'd just draw what you want to draw. You will lose the ability to debug the elements directly in the browser (in case you found that helpful with SVG).

So I'd say SVG v.s. Canvas is a draw. As time goes on, we can assume libraries driving Canvas will improve and multiply, until the next standard superseding both SVG and Canvas may get invented, who knows. Canvas is newer, so maybe SVG is more stable in browsers than Canvas is. Choosing SVG would be slightly more conservative then, but it seems no browser can afford crashing its Canvas developers too much.

The event model in SVG is the same as with html elements, while in Canvas there's more than one approach, I'd look at the event models as a key facet to consider.

All I can say about using libraries for driving SVG is, well, that it's not that cool and you spend time fiddling with the library rather than pursuing your design of what your application should be actually doing. Look at Canvas driving libraries for juxtaposing with SVG, not at bare Canvas... I would explore
KineticJS as a Canvas driving example.

Of course, if you're looking for ready made visualizations for which you'll have partial control of customizing, then SVG based libraries may have the upper hand as they've had more time to hone and grow those visualizations. d3.js being a case in point.

Jack

Sat, 25/08/2012 - 12:50

Hi Matan, Thanks so much for your considered and detailed reply. I agree with all you say. Canvas + a decent library would be a good solution. By the way: for the time being, I've stopped working on a web interface for my project. Instead I'm using GTK+. I need to get the "conceptual heart" (the mathsy stuff) of my code working as quickly as possible and then I can start tinkering with HTML5 GUIs and stuff like that.

Add new comment