In the development and build out of our core product, HTML5 Charting Library, ChartIQ weighed which technology would deliver the best performance for our time series charting library.
The introduction of HTML5 gave us two new options for data visualization technologies and the promise of being able to do graphics directly in HTML5 (no more Flash, Silverlight and Java). Our goal was to build a financial charting library that was as visually immersive as possible, while still providing a seamless user experience (UX). We weighed both HTML5 options – Canvas and SVG – and here’s what we discovered.
Scalable Vector Graphics (SVG) gave us what initially looked liked advantages: SVG is easy to understand and as part of the DOM, every object is represented on the screen. Everything from CSS styling to hover and click state manipulation, iteration through the DOM is made easy. SVG also made printing advantageous because SVG is vector-based and therefore has the ability to infinitely scale. SVG also offers easy to style animation and convenience features with the look and feel one would expect out of a modern HTML5 application.
In comparison, Canvas was raw and pixel-based. If you’re old enough to know what programming on the Atari 400 was like – Canvas is reminiscent of those days. The Canvas element is simply a large XY grid of pixels and gives the developer freedom to decide everything else. Initially, we thought it felt very rudimentary. But we quickly changed our minds, and here’s why.
We needed the ability to render huge amounts of market data, quickly, and with fluid user interaction (panning, zooming, etc.). When we evaluated performance, we found that SVG performance degrades logarithmically based on the number of objects that run on the screen.
Canvas on the other hand, had high-performance and was able to handle real-time mathematical operations and animations. Canvas degrades linearly based on the number of pixels that are in the canvas rather than logarithmically based on the number of objects. Imagine building for an iPad with retina display – you have a relatively low performance CPU and GPU, but you have a lot of pixels. This is your worst-case scenario, and one which you can optimize for in advance.
With SVG if you have 10, 50, 500 objects on the screen – performance is stable – but the moment that you have a 1000, 5000, 10,000 objects on the screen – SVG grinds to a halt. This makes it great for pie charts, bar charts objects and the occasional scatter plot, but not performant enough for real time financial charts with thousands of data points.
At ChartIQ, we love video games and were inspired by game developers process when building out our financial data visualization software.
Desktop and console games were always coded in C++ for maximum performance. If you play a game on the web, a phone or a tablet, chances are it’s been built on top of HTML5 Canvas. Why? Because the companies that build gaming engines realized that only Canvas – not SVG – could handle the performance requirements of immersive video games.
Game developers don’t start with the raw canvas though – that would be like mining for minerals before building a skyscraper. Game developers build on top of gaming engines, which handles all the complex functions required for building great games: physics, layout, sprite animations, building levels, and all the rest. Depending on what kind of game you want to build – a side scroller vs. a first person shooter, for instance – you pick the most appropriate gaming engine. This is how game developers are able to focus on building the game engine they want to build, and don’t waste time building out the physics engine that underlies it.
We wanted to provide this exact same environment and experience to developers who are building the next generation of financial applications. Developers can now focus on exactly how they want to build their application – the user experience and workflow – knowing they have a supercharged charting engine under the hood.
Contact us to learn more about our HTML5 charting library
