Blog

HTML Graphics: SVG vs. Canvas

The HTML5 specification provides two ways for generating graphics, by use of the <svg> and <canvas> elements.

 

Both of these elements enable the developer to dynamically generate and display graphics in a HTML5 compatible browser. Such abilities are useful for creating animations, games, generating charts as well as many other applications.

 

Utilizing these elements each require their own distinct approaches and provide benefits unique to their individual abilities. This article will give an overview of both elements as well as provide a comparison between the two elements.

 

Overview

 

<svg>

 

SVG is an acronym that stands for Scalable Vector Graphics. The <svg> element provides a mechanism for creating, manipulating and animating scalar graphics in a HTML page. The key, defining feature of vector graphics is their ability to scale to any size. Objects within the graphic are defined by coordinates, lengths, widths and other geometric properties. The graphics are generated based on these definitions so can be scaled to any size and mapped to any coordinate system. A good example of vector graphics are Adobe PDF files. These files, when viewed, can be magnified to any degree without losing resolution.

 

SVG provides the ability to define this style of graphic. Based on XML, geometric objects and their associated properties can be defined using the same protocol used to create other extensible markup. SVG defines a number of objects (rect, circle, path) that can be included in a SVG definition. A browser will read this definition and render the objects as declared. Furthermore, these objects may be manipulated using JavaScript and styled using CSS. Using these abilities a developer may animate the graphic and/or enable the graphic to respond to user input.

 

SVG may be defined inline or stored in a .svg file and embedded in the HTML document. Since the graphics can be defined and stored in this manner, SVG is considered “retained” mode graphics.

 

<canvas>

 

The canvas element approach to generating graphics is geared toward a programmatic implementation. A canvas element is included inline on a web document. This element can almost literally be thought of as a canvas. The developer is expected to write code that will apply graphics to this canvas. Graphics are generated using function calls and a well-defined API, similar to other graphics APIs. No DOM manipulation is utilized to achieve the desired graphic, all is accomplished with calls to the API.

 

Canvas is considered an “immediate” mode engine. That is, graphics are sent to the canvas but are not accessible after being rendered. The implication of this is that further changes to the canvas are done by re-drawing the entire graphic as opposed to acquiring a handle to the graphic and manipulating properties. A further implication is that capturing user interactions is not inherent as no event handler can be tied directly to the graphic.

 

Canvas is based on raster graphics. Raster graphics are defined by coloring pixels along a x-y coordinate system. This is the method used by many image formats such as .JPG and .GIF. Raster images do not scale well. They will become pixelated and/or distorted if shifted to a smaller or larger size.

 

Canvas and SVG compared

 

Both forms of graphics have their benefits and set of intended use cases. Generally speaking, SVG excels at presenting scalable images that can easily interact with the user. Canvas excels at generating more complex graphics and animations, games are a good example where canvas would likely be a good fit.

 

The table below from the Microsoft website and provides a good comparison between Canvas and SVG

 

Canvas

SVG

Pixel based

Shape based

Single HTML element

Multiple graphical elements, which become part of the DOM

Modified through script only

Modified through script and CSS

Event model/user interaction is granular (x,y)

Event model/user interaction is abstracted (rect, path)

Performance is better with smaller surface, a larger number of objects (>10k), or both

Performance is better with smaller number of objects (<10k), a larger surface, or both

 

 

 

LINKS

https://msdn.microsoft.com/en-us/library/gg193983%28v=vs.85%29.aspx