Html5 Canvas Vs. Svg Vs. Div

HTML5 Canvas vs. SVG vs. div

The short answer:

SVG would be easier for you, since selection and moving it around is already built in. SVG objects are DOM objects, so they have "click" handlers, etc.

DIVs are okay but clunky and have awful performance loading at large numbers.

Canvas has the best performance hands-down, but you have to implement all concepts of managed state (object selection, etc) yourself, or use a library.


The long answer:

HTML5 Canvas is simply a drawing surface for a bit-map. You set up to draw (Say with a color and line thickness), draw that thing, and then the Canvas has no knowledge of that thing: It doesn't know where it is or what it is that you've just drawn, it's just pixels. If you want to draw rectangles and have them move around or be selectable then you have to code all of that from scratch, including the code to remember that you drew them.

SVG on the other hand must maintain references to each object that it renders. Every SVG/VML element you create is a real element in the DOM. By default this allows you to keep much better track of the elements you create and makes dealing with things like mouse events easier by default, but it slows down significantly when there are a large number of objects

Those SVG DOM references mean that some of the footwork of dealing with the things you draw is done for you. And SVG is faster when rendering really large objects, but slower when rendering many objects.

A game would probably be faster in Canvas. A huge map program would probably be faster in SVG. If you do want to use Canvas, I have some tutorials on getting movable objects up and running here.

Canvas would be better for faster things and heavy bitmap manipulation (like animation), but will take more code if you want lots of interactivity.

I've run a bunch of numbers on HTML DIV-made drawing versus Canvas-made drawing. I could make a huge post about the benefits of each, but I will give some of the relevant results of my tests to consider for your specific application:

I made Canvas and HTML DIV test pages, both had movable "nodes." Canvas nodes were objects I created and kept track of in Javascript. HTML nodes were movable Divs.

I added 100,000 nodes to each of my two tests. They performed quite differently:

The HTML test tab took forever to load (timed at slightly under 5 minutes, chrome asked to kill the page the first time). Chrome's task manager says that tab is taking up 168MB. It takes up 12-13% CPU time when I am looking at it, 0% when I am not looking.

The Canvas tab loaded in one second and takes up 30MB. It also takes up 13% of CPU time all of the time, regardless of whether or not one is looking at it. (2013 edit: They've mostly fixed that)

Dragging on the HTML page is smoother, which is expected by the design, since the current setup is to redraw EVERYTHING every 30 milliseconds in the Canvas test. There are plenty of optimizations to be had for Canvas for this. (canvas invalidation being the easiest, also clipping regions, selective redrawing, etc.. just depends on how much you feel like implementing)

There is no doubt you could get Canvas to be faster at object manipulation as the divs in that simple test, and of course far faster in the load time. Drawing/loading is faster in Canvas and has far more room for optimizations, too (ie, excluding things that are off-screen is very easy).

Conclusion:

  • SVG is probably better for applications and apps with few items (less than 1000? Depends really)
  • Canvas is better for thousands of objects and careful manipulation, but a lot more code (or a library) is needed to get it off the ground.
  • HTML Divs are clunky and do not scale, making a circle is only possible with rounded corners, making complex shapes is possible but involves hundreds of tiny tiny pixel-wide divs. Madness ensues.

SVG rect vs div vs canvas

3000 DOM objects with events attached is going to be very painful for some machines to handle. Generally once you get into the "thousands" range the performance of DOM-based solutions (divs, SVG) gets really bad. It is nigh impossible to get good loading times with that many DOM elements.

The performance of excanvas itself is also really bad. The second there is any animation the performance of excanvas turns awful. Since excanvas merely mimicks Canvas by making VML (SVG), its going to be at least just as slow (and almost always slower) than doing just SVG/VML alone.

See my answer here for a detailed analysis: HTML5 Canvas vs. SVG vs. div

I believe that one of the requirements on your list has got to go. The number of objects, the performance, or the platform.

My suggestion to you would be to drop support for the older browsers if possible and go with Canvas.

What is the difference between SVG and HTML5 Canvas?

See Wikipedia: http://en.wikipedia.org/wiki/Canvas_element

SVG is an earlier standard for drawing
shapes in browsers. However, SVG is at
a fundamentally higher level because
each drawn shape is remembered as an
object in a scene graph or DOM, which
is subsequently rendered to a bit map.
This means that if attributes of an
SVG object are changed, the browser
can automatically re-render the scene.

In the example above, once the
rectangle is drawn, the fact that it
was drawn is forgotten by the system.
If its position were to be changed,
the entire scene would need to be
redrawn, including any objects that
might have been covered by the
rectangle. But in the equivalent SVG
case, one could simply change the
position attributes of the rectangle
and the browser would determine how to
repaint it. It is also possible to
paint a canvas in layers and then
recreate specific layers.

SVG images are represented in XML, and
complex scenes can be created and
maintained with XML editing tools.

The SVG scene graph enables event
handlers to be associated with
objects, so a rectangle may respond to
an onClick event. To get the same
functionality with canvas, one must
manually match the coordinates of the
mouse click with the coordinates of
the drawn rectangle to determine
whether it was clicked.

Conceptually, canvas is a lower level
protocol upon which SVG might be
built.[citation needed] However, this
is not (normally) the case—they are
independent standards. The situation
is complicated because there are scene
graph libraries for Canvas, and SVG
has some bit map manipulation
functionality.

UPDATE:
I use SVG because of its markup language abilities - it can be processed by XSLT and can hold other markup in its nodes. Similarly I can hold SVG in my markup (chemistry). This allows me to manipulate SVG attributes (e.g. rendering) by combinations of markup. This may be possible in Canvas but I suspect that it's a lot harder.

HTML5 SVG vs Canvas for big number of lines?

Generally svg is better suited for vector images, like in your example. However canvas has a lot of benefits in modern browsers such as hardware acceleration, so for drawing the lines, as long as zooming, panning ect. isn't required performance will be using canvas.

Mouse events can be a pain using canvas, since you have to manually keep track of everything, so with 5000+ points using canvas it wont be fun. The trade off however will be once the points are drawn, assuming you only draw them once the page will behave fine regardless of the number of lines, since they are all drawn to a raster image and aren't part of the DOM.

Honestly though the best way to find it is to test what you currently have using canvas.

HTML5 Canvas vs SVG/VML?

HTML5 Canvas is simply a drawing surface for a bit map. You set up a draw (Say with a color and line thickness) , draw that thing, and then the Canvas has no knowledge of that thing: It doesn't know where it is or what it is, it's just pixels. If you want to draw rectangles and have them move around or be selectable then you have to code all of that from scratch, including the code to remember that you drew them.

On the other hand, every SVG/VML element you create is a real element in the DOM. By default this allows you to keep much better track of the elements you create and makes dealing with things like mouse events easier by default.

Canvas would be better for faster things and heavy bitmap manipulation (like animation), but will take more code if you want lots of interactivity.

Canvas vs. SVG for games

SVG V Canvas

As a professional games creator my advice is to stay away from SVG if you wish to create browser based games. The main reason is that it is simply too slow. Second reason is that it will make your job as a programmer more difficult because finding solutions to SVG's lack of performance is hard. Third reason, because it is VERY SLOW and games are all about performance.

This page will go over SVG game design An Original Approach to Web Game Development Using SVG but before you dive in and read all of it have a look at the prototype of the game it`s all about Runes and Relics Prototype. A little oh hum in my book.

I am sure there are other attempts this was just first up in my search. But I have never played a good SVG game.

So what is SVG good for? Graphic resources. SVG is a good way to package images for your game, Once you have them on the client you can render them to bitmaps and then use them to render your game. The beauty is you get the resolution independent scalability of SVG and small images size. But by rendering them to bitmap at load time you get the full use of the GPU to move pixels about. SVG is just too slow to use within the game.

Why use Canvas? I would like to say because it's fast, but it is not when you compare it to a native C++ app which will run 10* quicker than the equivalent Javascript / canvas game. Ten times quicker is very significant but then you do not get the cross platform advantage you get with Javascript.

Currently canvas is the best option for truly cross platform game applications. Using either 2D or 3D webGL you can build full screen full frame rate games. HTML5 has a good set of APIs for all gaming needs and is easy to learn.

I am not a fan of game engines, they are a cover all solution, the middle man between you and the already well designed API's that force you to do it their (not that great) way. But they will give you a good overview of what is possible.

Phaser is a javascript canvas game engine that has lots of resources and examples. It is a good place to start and see what can be done. Don't be sucked in by the fact that game engines sell themselves as such. HTML5 & JavaScript is out of the box the best game engine in town, runs native code, has a huge user and support base. The time you spend learning how to use a Game engine's API will not be time spent learning how to use the HTML5 API's (and quite frankly the HTML5 APIs are perfect, the result of the 20 year browser wars) which is actually easier than the Game engines to use and learn.

SVG vs HTML5 Canvas Based Charts

Projects with a large amount of data may favor canvas. SVG approaches typically create a DOM node per point (unless you make paths), which can lead to:

  1. An explosion in the size of your DOM tree

  2. Performance problems

Using a path, you can get around this problem, but then you lose interactivity.

Say you're building a stock chart. If you are talking about a chart with, say... max 5 years and end of trade data samples only, I think the answer is clearly SVG. If you're talking about looking at Walmart's historical data from day one of trading or doing full trade information per minute, you are going to have to really look carefully at SVG. Probably will have to employ fancy memory management and a fetch-on-demand approach as SVG will fall apart, particularly if you go one sample to one SVG node.

If interactivity is a requirement, SVG easily has the edge, given:

  • It is a retained mode API
  • You can use typical event handlers
  • You can add/remove nodes easily, etc.

Of course, you see that if you require full interactivity, it may go against mechanisms that allow SVG to scale, like path collapsing, so there is an inherent tension here.

There is going to be a trade-off in extremes. If size is small, the answer is SVG hands-down. If size is large and no interactivity, the answer is SVG with path drawing only or using Canvas. If size is large and interactivity is required, you have to go canvas or tricky SVG, which is complex in either case.

Some libraries out there offer both canvas and SVG renders, such as ZingChart and Dojo. Others tend to stick with just one of the two options.



Related Topics



Leave a reply



Submit