This post follows on from the comparisons by Colin, of two Silverlight chart libraries, and Graham, of Flex and Silverlight chart libraries. In this post I add an HTML5 chart library into the mix. The results show that the HTML5 Charts perform easily as well as the others in HTML5 browsers (Chrome, FireFox, Safari, Opera, IE9*).
* Note this is predicted performance in IE9 as the library does not yet support it during its preview phase, there is work being done on this.

There's been some interest in how Flex, HTML5 and Silverlight stack up against each other, and whether there's any stand out reason to choose one technology over the others. To aid in this comparison I've reproduced the example from Colin and Grahams posts using an open-sourced charting library.

Closure Charts

The charting library is called Closure Charts, an open source project managed by Scott Logic aimed at producing fast and functional charts without requiring any browser plug-ins. It is built on top of the Closure Library framework and is fully annotated for use with the Closure Compiler. It has support for VML, SVG and canvas based rendering which means that it works on virtually all desktop web-browsers (including IE 6-8) and most smartphone browsers. For more information on the library visit the website on Google Code.

HTML5

I think at this point it would be helpful to share my personal definition of HTML5 as it's a highly overloaded term in much the same way as web 2.0 was/is-

  • A next generation JavaScript engine (10/100x performance improvement on the previous generation)
  • New JavaScript APIs, e.g. WebWorkers, WebSockets, XDomain AJAX
  • New standards CSS3 (brings with it layout concepts, transitions etc...), SVG (persistent mode graphics)
  • New tags including Canvas (also Video, Audio but less relevant)

The often quoted problem with HTML5 is the limited availability of the above features. Whilst is is true that support for most features is limited to the current versions of the non-IE browsers and the yet to be released IE 9, putting HTML5 support at approximatly 50% of desktop browsers and 60% of mobile browsers (statcounter.com). It is not true to say that this means we can't start using those features, and in many cases drag the legacy browsers along for the ride. Abstraction libraries make it possible to target many HTML5 features and be confident of them running on legacy browsers. I'd recommend watching this video, for a very passionate and informative talk on this very topic. (thanks Matt!).

Unfortunately in this example we require functionality that is only provided by the canvas element, specifically Context2D.getImageData which allows the retrieval of pixel data from an image. For this reason the below example only works in browsers which support the canvas tag, so no IE 6-8 support. However, I think it's fair to blame the example rather than the technology here, as I'm struggling to think of a genuine need for pixel data extraction in most circumstances.

Implementation

Here are the examples of the three different technologies -

HTML5 Chart Flex Chart Visiblox Chart
[kml_flashembed movie="/archive/2010/11/FlexChartsPerformance.swf" height="380" width="280" /]
Get Microsoft Silverlight

Image credit toClevergrrl

The example is implemented as a Closure Component, an interesting snippet is the mouse move code which is very similar to the Flex example -

if (this.startPos) {
	/** @type {goog.math.Coordinate} */
	var canvasPos = goog.style.getClientPosition(this.canvas);
	/** @type {goog.math.Coordinate} */
	var endPos = new goog.math.Coordinate(e.clientX - canvasPos.x, e.clientY - canvasPos.y);
	// compute length of line
	/** @type {number} */
	var length = Math.floor(Math.sqrt(Math.pow(this.startPos.x - endPos.x, 2) +
				   Math.pow(this.startPos.y - endPos.y, 2)));
	if (length > 1) {
		// draw the visible line
		this.ctx.drawImage(this.image, 0, 0);
		this.ctx.beginPath();
		this.ctx.moveTo(this.startPos.x, this.startPos.y);
		this.ctx.lineTo(endPos.x, endPos.y);
		this.ctx.closePath();
		this.ctx.stroke();

		// rebuild the chart data
		goog.array.clear(this.seriesRed.points);
		goog.array.clear(this.seriesGreen.points);
		goog.array.clear(this.seriesBlue.points);
		for (var i = 0; i < lineLength; i++) {
		/** @type {number} */
		var xIndex = Math.floor(this.startPos.x + (endPos.x - this.startPos.x) * i / lineLength);
		/** @type {number} */
		var yIndex = Math.floor(this.startPos.y + (endPos.y - this.startPos.y) * i / lineLength);
		/** @type {number} */
		var index = yIndex * this.size.width * 4 + xIndex * 4;
		this.seriesRed.points.push([i,this.canvasPixelArray[index]]);
		this.seriesGreen.points.push([i,this.canvasPixelArray[index + 1]]);
		this.seriesBlue.points.push([i,this.canvasPixelArray[index + 2]]);
		}

		// update the chart display
		this.chart.redraw();
	}
}

Conclusion

I'm able to conclude in much the same way as Graham, from the above examples it is apparent that there is little, if anything, to differentiate their relative performance once loaded. Furthermore, it would be fair to say that the outright technology choice of HTML5, Flex or Silverlight has not differentiated these examples. Rather, the choice of charting library in either technology is far more significant with respect to performance.

However, I think a distinction can be drawn in terms of loading time. The HTML5 example initialising with the rest of the page, whereas both the plug-in based approaches have a noticeable loading lag, both network before they are cached, and plug-in initialisation once cached. Here, the HTML5 version has two clear advantages -

  • The example itself weighs in at only ~65kB (including image, transferred size) versus ~225kB for Flash and ~285kB for Silverlight.
  • There is no plug-in to initialise, a very big advantage of targeting the "native runtime".

So in conclusion, if loading performance, cuteness or mobile support are crucial to your component/application then HTML5 is a very strong contender.

Chris