How to Choose Between Canvas and SVG for your Site

Canvas and SVG are two exciting graphics features introduced in Internet Explorer 9 and are hardware accelerated. These technologies can be used to address a range of graphic scenarios on the modern Web. With a lot of excitement around Canvas, there has been a tendency to ignore SVG, which, in many

Editorial Note

This article is in the Product Showcase section for our sponsors at CodeProject. These reviews are intended to provide you with information on products and services that we consider useful and of value to developers.

High Level Summary of
Canvas and SVG

The
following is a high-level summary of Canvas and SVG meant to frame a discussion
of when to use one particular vector graphic technology over the other.

A Comparison of Canvas and
SVG

Canvas

SVG

Pixel-based (canvas is essentially an image element with a
drawing API)

Object Model-based (SVG elements are similar to HTML elements)

Single HTML element similar to <img> in behavior

Multiple graphical elements which become part of the Document
Object Model (DOM)

Visual presentation created and modified programmatically
through script

Visual presentation created with markup and modified by CSS or
programmatically through script

API does not support accessibility; markup-based techniques
must be used in addition to canvas

SVG markup and object model directly supports accessibility

SVG is
known as a retained mode graphics model persisting in an in-memory
model. Analogous to HTML, SVG builds an object model of elements, attributes,
and styles. When the <svg> element appears in an HTML5 document, it
behaves like an inline block and is part of the HTML document tree.

Canvas
is a bitmap with an immediate mode graphics application programming
interface (API) for drawing on it. Canvas is a “fire and forget” model that
renders its graphics directly to its bitmap and then subsequently has no sense
of the shapes that were drawn; only the resulting bitmap stays around.

One
way to think of these is that Canvas resembles the Windows GDI API, where you
programmatically draw graphics to a window, and SVG resembles HTML markup with
elements, styles, events, and DOM-based programmability. Canvas is procedural
whereas SVG is declarative.

The Scenarios

The
following sections describe the technical benefits and limitations of both
technologies, including a common sense approach to determining when one is
appropriate for a given task. The illustration below illustrates where each
scenario falls on a spectrum from Canvas to SVG with a clear cross over point
in the middle.

Vector Graphic Spectrum

High
Fidelity Complex Vector Documents

High
fidelity complex vector documents have been, and will continue to be, the sweet
spot for SVG. Highly detailed for viewing and printing, standalone or those
embedded in a Web page. The declarative nature of SVG provides for tooling or
client or server side generation of shapes from databases.

The
first image shows the diagrams, while the second image shows these diagrams
zoomed in to 1000%

When
you consider the usefulness for observing a large schematic, but the need to
drill into the detail, or print the entire document for engineering purposes,
the “scalable” in Scalable Vector Graphics becomes
abundantly clear. For these reasons, we put high fidelity complex vector
documents at the SVG end of our spectrum.

SVG
as an Image Format

Another
common use for SVG is for static images within a Web page. With present-day
high DPI monitors, developers must take into account the quality of graphics.
The images below represent potential <li> bullet images styled via CSS.
The following images are almost identical in presentation and file size.

SVG graphic on left, PNG rendering of it on right

If the
developer wishes to reuse that image on a larger scale, or if the end user uses
a high-DPI screen, the raster image becomes pixilated, or the need for a larger
version of the file is necessary to preserve the fidelity.

Zoomed SVG graphic on left, zoomed 4K PNG on right

SVG
can thus serve as a nice image replacement format for even the simplest of
images on a Web page. A suitable replacement by Canvas is not available.

On the
other side of the spectrum, canvas brings speed to scenarios that don’t require
retention of what was drawn. When Canvas was first introduced, many fun
experiments were developed. I break these into three different scenarios.

Pixel
Manipulation

Because
Canvas is all about drawing and manipulating a pixel-based drawing surface,
several experiments and showcases of Canvas include sophisticated algorithms to
achieve impressive graphic effects such as ray tracing or filters.

The example below
was written by Adam Burmister. The experiment creates an image by tracing the
path of light through pixels on an image plane and simulating the effects of
its encounters with virtual objects.

The
author himself includes the following warning: “This is very CPU intensive.
Your browser may appear to stop responding.” Therefore, though the Canvas API
is capable of generating pictures such as this, it may not be such a good idea.
As site author Adam Burmister summarizes,
“Ray-Tracing [is] The Worst Application of JavaScript Ever.”

The
same can be said for other scene-wide pixel manipulation. The following
function replaces green pixels in one canvas with pixels from another,
identically-sized canvas. A function such as this could be used with to create
a video “green screen” effect.

It was
a fun experiment, but like the ray-tracing example above, performance on
today’s machines falls short. I call these out though for one primary reason:
such pixel manipulation is simply not possible with SVG. It is the
differentiating factor between the two technologies. One manipulates pixels
while the other manipulates a model.

Whether
creating realistic images from otherwise simple vector graphics or creating
green screen effects with video, these graphic scenarios are, in most cases,
simply not ready for prime time deployment on the today’s Web. However, certain
scenarios are responsive enough (such as applying filters to remove red eye in
photos). These pixel manipulation scenarios fall on the far left on the
spectrum as a canvas scenario.

Hybrid
and Crossover Scenarios

The
most interesting set of use cases didn’t indicate a clear winner. These are
illustrated with two primary scenarios: Charting/Graphing/Mapping and
Two-dimensional Gaming.

Charts
and graphs require vector graphics and either Canvas or SVG will work. However,
SVG is the often then better choice due to its intrinsic capabilities.

In
fact, it requires 2,878 path-drawing directives (moveTo, lineTo, and
bezierCurveTo) to draw this complex map of Alaska. Of course, lower resolution
versions of this map are possible. Considerably fewer lines of code would be
required for Wyoming and Colorado.

SVG
mapping-based applications typically include an interactive experience
involving hover effects, selection, tabbing between items, and scaling. These
operations require only lightweight HTML concepts when using SVG, for example,
for processing a mouse event:

In
canvas, creating either of these effects requires you code your own hit
detection using the event object’s mouse coordinates. You no longer have the
context of the shape. While there is the isPointOnPath() API, it only applies
to the last path created.

Code
can and does exist in the form of graphing libraries to enable specific hit
detection on graphs using pixel data to identify hits and hovers and are
functional. They also exist for SVG and will have better performance if
designed to take advantage of the SVG features.

Canvas
Charting/Graphing Scenarios

Canvas
has its place for charting and graphing scenarios. To set context for this, we
need to examine the performance characteristics of both SVG and Canvas.

Sometimes
there are outside influences that require a choice of technology that is, or is
mostly, independent of functionality. For SVG and Canvas, there are two primary
differentiators.

Developer
knowledge, skill set, and existing assets will play a significant role into the
choice of technologies. If while creating a game, the developers have deep
knowledge of low-level graphic APIs and limited knowledge of Web technologies,
the likely technology to choose is Canvas (more on this later). In porting
games, there are tools that support moving from third party implementations to
Canvas.

If
performance is critical, often down to milliseconds, it is necessary to compare
the performance characteristics of the two technologies. This does not mean
that Canvas, typically considered highly performant, is the obvious choice.
However, for applications with large amounts of data that must be drawn at the
pixel level, Canvas is by far the better choice.

The
weather map below does not require a large surface area, and the number of
objects on the screen is considerably high. With Canvas, these can be quickly
drawn without the cost of updating a DOM.

While
the above image could be fully created in SVG using circle or ellipse elements
for the dots, the time to load many thousands of elements into the DOM would
simply be too slow. Wherever you see a large number of pixels or images, this
is a good clue that Canvas is the technology to use—whether this is astronomy,
biological cellular movement, or voice modulation displays. The limits here on
how fast data can be visualized are the speed of the CPU, the speed of the
Canvas implementation, and the speed of the JavaScript implementation.

Two-Dimensional
Games

Casual
gaming was the most complicated scenario to explore. Some initial observations:

Gaming libraries have leveraged lower level graphic APIs

Developer skillsets for the gaming industry are tuned towards
these lower level APIs

Many games are largely image- or sprite-based

Vendors such as Adobe are beginning to support Canvas as an
export

Casual games do not often require sophisticated hit testing

Casual games do not usually have a prohibitively large number of
“objects”

In
gaming libraries, for example, popular physics engines, the graphics model is
independent and graphics becomes an implementation detail. Graphing geometries
such as boundaries, velocities, sizes, and positions are delivered to engines
that subsequently respond with velocities, collisions, and positions. Graphics
are used only to get the computed scene to the screen.

The
concept of graphics being independent of the gaming logic is demonstrated by
two games, developed by the same author, intended to highlight both SVG and
<canvas>: SVG-oids
and canvas-pinball.

While
the game and demonstration logic is different, both are leveraging the same
physics engine, which tracks positions, collisions, velocities, and other
physical aspects of the gaming components. In the end, one utilizes SVG to draw
(or move) the elements of the game and the other redraw them with Canvas.

Most
2D casual games that are built today for HTML5 are using Canvas so we place
this scenario toward the Canvas side of the cross over point.

The
Hybrid Scenario

Casual
gaming also falls into the hybrid scenario is because there is an advantage to
leveraging the best of both technologies. For easy hit detection and user
interaction, a mostly opaque layer of SVG geometries can be used to position
elements while the underlying Canvas can more quickly position relevant images
and provide real-time animations.

There
is a growing number experiences outside the casual gaming segment that are
finding it compelling to use a hybrid. When a scenario contains both the need
for visually intense dynamic graphics and animations (Canvas) as well as rich
user interaction (SVG), both of these technologies can and should be used. This
is represented by the Brain Power
site from one of our partners showcased on The Beauty of the Web
site. This Brain Power site—and others featured on The Beauty of the Web—have
found this delicate balance.

For
user interaction and displaying portions of the brain, the site leverages the
higher-level geometries of SVG:

Conclusion

The
analysis of existing vector graphic technologies available in the latest modern
browsers shows new scenarios can be created using standard Web technologies in
an interactive way. Check out these videos for more information on how to
develop for Canvas and SVG:

The
ongoing evolution of the Web continues to include richer graphics at its heart.
We’ve presented one point-of-view about applying these technologies to
particular scenarios. In the end, both Canvas and SVG are important components
of the HTML5 graphically rich Web.

We’d
love to hear how you’re applying these new HTML5 technologies to your Web
sites. Include URLs and, please, make sure your page works in IE9 by
including the HTML5 doctype, <!DOCTYPE html>, and using feature detection
not browser detection to know if SVG or Canvas are supported.

Share

About the Author

Comments and Discussions

hm, brainpower link does not work at all, beauty asks me to download IE
is there any better example of combination? i'm interested about both technologies in the same rectangle (= over) for something like simple drawing program - quite static background and dynamic lines over it, does this somehow depend on IE? what about something else like webgl simplified to 2d? (but here is IE out of game), how it is with google maps and similar projects implementation?
yours web-technologies amateur