Canvas is a pixel-based representation like a paint program. You can draw shapes over each other and they will modify the pixels. SVG is more like a drawing program where shapes are always there even if they get covered up.
Canvas is a stack-based API where you set the color and line style, move to a spot, draw some lines, set another color, draw more lines, etc. Almost all graphical libraries impliment this becuase in many situations it's more convenient and efficient than passing the parameters with each call. SVG is a tree representation where you can group objects and apply fill color, for example, to the whole group that get applied for every member that doens't explicitly specify their own fill color. Some things are cleaner to do in one model or the other. See Canvas and SVG slides by Robert O'Callahan at mozilla.org for a good overview about why the web needs both.
It was easiest to get SVGPlot to efficiently generate clean SVG code using a combination of DOM tree manipulation and Canvas calls. Why would you want this?
- The Canvas API is a nice API to build up an SVG without explicit DOM manipulations.
- When your browser supports SVG not canvas.
- Code written for canvas can be usedto create an SVG.
- Save the result of canvas calls to an SVG file for later display, conversion to PDF or PNG, or printing at high-res.
- Can apply events to objects (shapes) rather thanhave to translate the (x,y) coordinates like you do in Canvas.
When wouldn't you use this?
- When speed matters. With this, you just stack SVG shapes on top of each other forever. Even you clear it, those others will still be around taking memory and rendering time. For things like games and photographic content, you want the "blast it to the screen and forget it" model.
- Sometimes the simplest representation of a graphic is a program to draw it (e.g. fractals, function plotting) rather than an XML-like description.
- When your browser supports canvas but not SVG
- live demo - Table of tests that you can modify and re-run client side. These can take up to a minute to render in Firefox.
- live demo 2 - More of the same.
- canvas extensions - Table of demos for extensions that added on top of the basic Canvas functionality.
Browse Code in SVN Repository
- Batik impliments the Java AWT API to draw directly to SVG.
goes the other way, rendering SVGs onto a canvas. SVG has a richer
(more complicated) set of things like arcs, andstroke-dasharray that are not
built into the Canvas API making it hard on them and easy on me.
Other things like shadows and
globalCompositeOperationare not straight forward to impliment without native SVG support.
- Cairo can render to bitmaps, PDF, PS, SVG, OpenGL, and others. It's API is similar to Canvas.
PostScript was a vector drawing state-machine-based language, PDF is a subset without the programming language pieces (conditionals and loops). Canvas is a drawing API inspired by PS and PDF. SVG is a scenegraph representation. It's like the difference between OpenGL and Open Inventor. All drawing of windows and widets in NeXT was done used PostScript, and in OS X using PDF. The advantage was that the same code that is drawing to the window can be used to draw to the printer without any translation.
Canvas, though simple, is quite powerful, supporting transparency, gradients, clipping, blending, bezeir curves, and others that Win32/GDI and QuickDraw2D, and Java's AWT do not. Except for transparency, these features come from PostScript.
|State-Machine / Stack-Based / immediate-mode||Scenegraph / retained mode|
Quartz 2D / QuickDraw 2D on OS X
Java AWT java.awt.Graphics2D
|Open Inventor/ Performer
OpenGL++ / Cosmo 3D / Fahrenheit
VRML / X3D
Sometimes you want direct access to the pixels. In photo manipulation, 3D per-pixel lighting and shading, non-linear transformations, displaying image or video, a smoke or fire effect, filters, or interval graphing techniques. Dealing with a 2D array of pixels is more efficient than drawing a rectangle for each pixel using vector-graphics techniques. Some of these are addressed in the SVG filters -- you can have your drop shadow and the advantage of SVG. The other advantage is being able to both read and write the pixel array.
Overview of Canvas API
Overview of my Canvas Implementation using SVG
There is a single object
SVGCanvas which acts like Canvas's 2D context
that you get from
getContext("2d"). Maybe I should have called it
SVGCanvas2dContext to keep my options open for 3D, but X3DCanvas is
probably a better route.
There were some decisions to be made regarding trading off speed to create the SVG, speed to render the SVG, generating clean factorized SVG. What happens when you draw, transform, draw, transform, draw, etc.
- Should SVGCanvas keep an explicit current transformation matrix and multiply each incomming coordinate by it and write out the transformed coordinates? This is what the Canvas and SVG renderers do internally? This produces ugly SVG with lots of decimal digits that have no relation to the often simple coordinates provided.
- Another option would be to construct a huge string of
transformations and include them in the SVG element:
transform="translate(75, 75) scale(0.4, 0.4) rotate(6)"This is how you would write SVG "by hand." The problem with this is that the transformations can get longer and longer. Another problem is that you lineTo() rotate() lineTo() before you emit a path with fill() and there is no way specify a single transformation for the whole path.
clip()or things like
fillRect()that call one of these.
Gradients, clipping paths, markers, patterns, and other objects that you define and use many times are created by standard Canvas methods or a Canvas inspired SVG-only one.
Overview of SVG Extensions
Since I want to be able to use this as an easy way to draw into an SVG rather than just a pure Canvas implimentation, there are several SVG specific features.
- You can pick the SVG group you're drawing into by setting
drawGroup. It lives in the state. All elements go into this group. (They have transformations applied to them from higher-level goups.)
- Actions like
fill()return the DOM element of the path or group that was created. Usually you ignore it.
- You can manipulate the state dictionary yourself with
applyStylesis part of the state. If you have an SVG group that already has styling properties you need, you can set this to just output the shape elements and let the styles be inherited.
- Every SVG element can be created directly with the current
transformation and style applied by passing appropriate arguments to,
text()funtion that takes a string and a position. A big shortcoming of canvas is its lack of integrated text. I've also added font and textAnchor properties to the state.
draw()action: To draw a shape that has both a
stroke(), in Canvas you set up the path, then call
stroke()to stroke on top of the fill. You can do that here too, but it would generate two seperate SVG elemtns rather than a single one with both fill and stroke properties. If you edit the SVG and drag around the fill, the stroke won't come with it. Within
stroke()I can look to see if I've just done a
fill(), but this check is inneficient. Every time you do a stroke you have to compare the current state and the element you're trying to fill (path, rect, etc) with the previous thing. Maybe this is worth doing rather than defining a whole new non-canvas-API function, but it's far easier to add a draw function to the canvas context that calls