Saturday, 19 January 2013

HTML5 and interactive graphs

The HiveMindMap project  uses HTML5 technology to present a zoomable diagram of hashtag connections. The promise of HTML5 is that it should be possible to write a web app once and have it run on many devices.
However, the reality is that while modern desktop browsers (Firefox, Safari, Chrome, Opera and IE9+) seem to work well the iPad has been particularly problematic. The performance gap between desktop/laptop machines and tablets proves to be quite large. Using pinch-to-zoom or swipe-to-drag on a first generation iPad is painful as there is a delay that is measured in seconds. There are various tweaks that I have tried along the way to try and up the speed:

Swapping SVG for Canvas

The current implementation of the visualisation is using SVG and the other major contender in the HTML5 stable for graphics is to use the Canvas API. Using the KineticJS library I was able to quickly recreate the basic graph drawing capabilities with zoom and pan behaviour but the rendering was not noticeably any better.

Hardware acceleration

Upping the rendering speed should in theory be possible if I can use a GPU to perform much of the heavy lifting.  One approach advocated here is to add CSS3 styles that suggest the use of hardware acceleration:
 -webkit-transform: translateZ(0);
This may have marginally speeded up manipulation on the iPhone but a visible form of tiling occurred where the screen was briefly divided into sections containing pre-pan images and post-pan images before the repaint catches up and all sections then render from the same scene.
Worse, on the desktop Chrome browser a pop-up div that is overlaid over the hardware-accelerated image was visibly blurred for some reason, making the text unreadable. I chose to turn this off.

One other CSS3 technique I trialled was to avoid use of the SVG transform functions to zoom and position the image and instead controlled zooms and pans by setting CSS3 translate styles. Surprisingly this would zoom the image without introducing pixelation - I had assumed that it would treat the rendered SVG vector as a raster in the re-scaling and introduce pixelation artefacts with the zoom. Unfortunately it was not noticeably faster than pure SVG based transforms so I reverted back to using those.

Limiting repaints

The main enhancement to help support low-performance devices was to limit the number of repaints generated by swipe or pinch gestures.  While a desktop browser can happily respond to every mouse event the touch gestures on a tablet or phone generates events at a rate faster than can be repainted.

SVG issues on iOS

Aside from the performance issues of the iPad/iPhone I have also found that the iOS devices differ from all other browsers in the calculation of coordinates (including OSX Safari). The calculations used to centre an SVG element on the screen are miscalculated on iOS and elements are positioned off-screen rather than centred.


Overall, I suspect it is not important to cater for smart phones as the limited display space is not conducive to large-scale visualisations like this mindmap. The iPad however would be a nice platform to cater for and it is frustrating that the performance lags when using HTML5 technologies. Newer versions of the iPad have faster processors and seem better but ultimately a native app may be the way to go.


  1. I am converting a d3 visualization to ipad via phonegap and am also surprised by the sluggish performance independent of touch/swipe, and this with just a handful of d3 animations. Have not made a serious pass at optimization yet, but wondering how much can be done at this point.

    1. Yes, it's disappointing. If you go down the native route I did see that there was an Objective C project to render SVG images using calls to the native IOS graphics libraries.
      I would be interested to hear if you have any breakthroughs on the web-based front though.