Scalable Vector Graphics (SVG) gave us what initially looked liked advantages: SVG is easy to understand and as part of DOM, every object is represented on the screen. Everything from CSS styling to hover and click state manipulation, and iteration through the DOM is made easy. SVG also made printing advantageous because SVG is vector-based and therefore has 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, HTML5 canvas was raw and pixel-based. If you’re old enough to know what programming on the Atari 400 was like - according to our CTO, the HTML5 canvas is reminiscent of those days (we swear that wasn’t our deciding factor in choosing canvas). The HTML5 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 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 something like the 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 - the 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.
We love games at ChartIQ and were inspired by game developers process when building out our data visualization engine.
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 the HTML5 canvas. Why? Because the companies that build gaming engines realized that only the 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 handle 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 wast 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.
Check out our charting library and see what you think.