High performance heatmap data-visualization in web
I recently performed a comparison of a handful of most popular and well-known web data-visualization libraries in the context of heatmap data-visualization.
To quickly introduce heatmaps, Wikipedia tells us “A heatmap is a graphical representation of data that uses a system of color-coding to represent different values”. My favourite example is a weather map, which shows the amount of rain, for example, over a map.
Heatmaps are among the most iconic data-visualization tools known to man, so naturally they are well supported by web data-visualization tools.
…or so one could assume.
While rather small, my comparison project covered the most well known libraries, such as Highchart, ZingChart, EChart and LightningChart. I quickly found out that even at the very top of the industry, there are severe restrictions at place.
Before digging to technical details, a disclaimer of my bias;
I am a developer of LightningChart JS, one of the competitors involved.
The LightningChart product-line was historically created in order to resolve the very problems that we’ll be touching in this article.
1. Restrictions on heatmap size
Data-visualization tools generally manage heatmaps by managing them as 2D grids (width x height). The heatmap dimensions are a crucial factor in regards to both performance and user application implementation. Let’s check a practical example:
You’re developing a weather map that is to visualize the rainfall in the United States, utilizing various monitoring stations sprinkled all across the country. To do this, you split the USA both horizontally and vertically into several smaller cells. In this case, the dimensions of the heatmap dictate how much physical area is represented by a single colour in the heatmap.
In my tests, I found that the older libraries (Highchart, ZingChart, etc.) performance starts plummeting when the dimensions exceed 200x200 range. Quick Google search tells us that USA is roughly 4500 kilometres wide and 2300 kilometres tall — dividing this area into 200x200 grid will result in single colour representing an area of ~260 square kilometres.
Naturally, this isn’t very realistic since the application wouldn’t be capable of differentiating between massive downpour over your head or 20 kilometres west.
What kind of “performance plummeting” am I referring to?
Preparation time, as in taking tens of seconds to display the heatmap.
Processor usage, as in rendering the device unusable due to the heatmap preparation utilizing 100% of CPU.
On top of these, another factor is the interact ability degree of the prepared heatmap — usually, heatmaps come with interactions like data cursor (drilling down to individual cell information by utilizing users pointer device), panning and zooming.
Now, we can see that heatmaps are not always simple — they can be extremely heavy to prepare and display — so let’s look at the other side of the comparison, the very much performance-oriented chart library LightningChart JS.
In the very same tests, LCJS could prepare heatmaps all the way to 3000x3000 in less than ten seconds (7.18 seconds to be precise) — this is 225 larger than the previously talked about 200x200 grid.
With the USA example, this would allow every kilometre step to be associated with its very own colour in the heatmap. This, combined with instantaneous zooming can enable some pretty powerful data-visualization applications.
2. Restrictions on updating data
Now that your impressive looking heatmap is ready, one might think about the logical next step of updating the data after some timeout. For example, with the USA rainfall map, animating the movement of rainfall between recent samples.
This is where performance truly becomes a limiting factor, since if your heatmap update takes 10 seconds, then this above visualization wouldn’t be very impressive 😃
From my testing, it seems that LightningChart JS is the only web chart that is capable of efficiently updating the heatmap data, since none of the other competitors could function even with miniscule heatmaps (100x100, 50x50, or even 25x25) when the heatmap is repeatedly updated in short succession.
LightningChart JS v.3.0 performed with fantastic refresh rates (>30 times per second) with as far as 1000x1000 size heatmap!
Long story short, heatmaps are heavy but LightningChart is here to help!
Stay tuned for more heatmap (and other data-visualization) updates — for example, how the new version release LightningChart JS v.3.1 changes these figures!
Here is a link to the referenced comparison project:
https://github.com/Arction/javascript-charts-performance-comparison-heatmaps
