SVG vs Canvas, what format to choose?
scriptol.com
scriptol.com
Here's an SVG site I wrote (it'll take a while to load and will only display in recent browsers). The way that it responds to mouse-overs is (relatively) easy to program in SVG because you can associate events with structure in the image - http://practi.cl/en/proj/pysrc/lepl/lepl#pkg-tab=b-dependenc... (it's showing package dependencies for a Python library).
To do something similar with canvas you would redraw sections instead of simply changing the properties of arcs, etc (and handling user clicks is lower-level - instead of getting the action associated with some "thing" in the image, you get a coordinate). Which is "best" depends on the application. The link above makes more sense in SVG because you've got logically distinct, overlapping components. But if you want a more static image, canvas is probably going to be simpler.
for example
var circle = document.createElementNS("http://www.w3.org/2000/svg, "circle"); circle.setAttribute("style", "fill:green"); circle.setAttribute("cx", 50); circle.setAttribute("cy", 50); circle.setAttribute("r", 25);
ctx.drawSvg(circle,x,y,w,h);
I think then we could have the best of both worlds, define complex shapes in svg, but use canvas for rendering. The advantage over just using svg is that every shape is in the dom, so if you want to draw 1000 similar shapes the dom gets cluttered.
Looks great in Chrome for me, aliased in Firefox.
The Processing parser generate (fast) javascript code on the fly the can be accessed from external scripts. You can mix processing with javascript.
An image in HTML canvas, is stored as a matrix of pixels. Individual pixels in the matrix, can be accessed and modified with canvas API methods.
The canvas drawing API allows to draw vector graphic primitives on the canvas, but these are immediatly rasterized as pixels. So the image is always a bitmap.
In SVG, an image is stored as a set of graphics primitives. There is a primitive that can hold external bitmap images. But there is no way to read or modify individual pixels. Only parameters in the primitive definition can be accessed.
In the Canvas it is possible to operate directly over pixels. In SVG only the mathematical definitions of the shapes primitives can be modified. So complex pixel procesing algorithms are possible with Canvas, but not with SVG.
Except for SVG path data of course, which are strings of 1-character commands (with parameters interspersed) in XML attributes. "M 100 100 L 300 100 L 200 300 z"? Why yes, I missed perl, thank you very much.
And don't forget: case matters…
I think this is misconception based on (mis)use of SVG as if it were canvas, where people destroy and re-create whole DOM each time picture changes. That's not how SVG is meant to be used — SVG is best when updated incrementally and animated declaratively.
SVG has advantage (and should be faster in a decent implementation) when you animate complex shapes: (linear) animation in SVG doesn't require touching of large number of DOM nodes — you just update an attribute of a single group. With SMIL you just trigger the animation and don't touch DOM again. This allows browser to handle repainting natively and cache group/shape bitmaps.
OTOH animation on canvas requires issuing hundreds of canvas drawing commands, from JavaScript, each frame, repeatedly.
On canvas if you want to move layer that is behind another one, you have to redraw all top layers. In SVG browsers are able to cache layers and use (GPU-)accelerated compositing. I can't find the link, but I've seen demo from Opera where they allow author to declare which parts of SVG change rarely and can be cached as bitmaps.
I wrote a prototype fence drawing app for ipad. Initial svg-only prototype turned out to be extremely slow. While in a mixed approach, svg gave flexibility of programming interactions while canvas helped me quickly render alterations in polygons of the fences as one touched and dragged.
Bottomline - SVG performance degrades as number of objects, Canvas performance degrades as size of the canvas. Mix both to get the best.
My recommendation is svg for static graphics/pictures, and canvas for animations/dynamic stuff, but keep the canvas as small as you can
I should do some more speed testing, but e.g. it's possible to get SVG to draw "markers" at every point in a single polygon, and fairly quickly in some renderers.
You could draw SVG markers at every point but with the DOM and everything, it just becomes very slow. protovis (a great SVG based library) mention the number 10,000 points at which SVG starts becoming unusable. I am able to plot 25k+ points.
For infoviz (although I don't have a formal background in it), I've always taken the approach of implementing more intelligent data point selection algorithms - better selections of what points to actually display, to maximize the information the user gets out of the graph, rather than trying to push as many data points per frame. Similar to improved LoD algorithms making 3d worlds better when raw pixel throughput in the 3d rendering path can't keep up.
Anyway my question is, in what circumstances do you need to render 25k data points per frame / render loop? Aren't there clusters of 10's or 100's of them who end up obscuring each other anyway?