As you might know, the JavaScript InfoVis Toolkit uses the HTML5 Canvas element for plotting and animating graphs. This is all very nice, Canvas performance compared to other techniques for plotting these things (SVG for example) is by far superior. But of course, there are drawbacks.
Canvas better performance is due to the fact that there are no tracked elements: the Canvas is simply an image and you’re drawing there just like you’d be drawing something in paint. One big problem is that there’s no native possibility to add events to what’s drawn in Canvas, like a plotted node, edge or label.
As opposed to Canvas, SVG has a DOM/XML like spec: you have all these tags (<g> <text> <rect>) and each of them is just like a DOM element: you can add click event handlers, individual styling with CSS, etc.
Having to keep track of all these elements and handling a DOM-tree makes the performance of SVG not suitable for visualizing (and animating) medium to large datasets on the web.
Using HTML labels
Just like SVG, HTML is a DOM/XML-like spec, where you can add event handlers to each element. Also, every web developer knows HTML so exposing HTML labels through user-defined controller methods in the library seemed to me like a good choice. For controller methods like onCreateLabel or onPlaceLabel an HTML element is passed and the user can style or add event-handlers to it.
For example, here’s a fragment of the code used in the RGraph demo. You can see the rest of the code here:
//Add the name of the node in the correponding label
//and a click handler to move the graph.
//This method is called once, on label creation.
onCreateLabel: function(domElement, node){
domElement.innerHTML = node.name;
domElement.onclick = function(){
rgraph.onClick(node.id);
};
},
//Change some label dom properties.
//This method is called each time a label is plotted.
onPlaceLabel: function(domElement, node){
var style = domElement.style;
style.display = '';
style.cursor = 'pointer';
if (node._depth <= 1) {
style.fontSize = "0.8em";
style.color = "#ccc";
} else if(node._depth == 2){
style.fontSize = "0.7em";
style.color = "#494949";
} else {
style.display = 'none';
}
var left = parseInt(style.left);
var w = domElement.offsetWidth;
style.left = (left - w / 2) + 'px';
}
In my opinion this is a good approach, good points are:
- I'm using well known HTML elements.
- Dealing with DOM elements let's you add event handlers, individual styling and things like that.
Weak points are:
- I'm using a DOM tree, which means that if labels are plotted at all times I'm exhaustively updating the DOM and this might lead to performance problems.
- HTML is good for structuring pages, but for example you might want to apply transformations to HTML elements (like rotating labels, etc), and these aren't supported by all browsers yet.
So one of the problems that might arise is, for example, the fact that in radial layouts labels might be occluded:
Using SVG labels
So I began exploring other possibilities to create labels. For this I abstracted the Label interface I had and split it into:
- Graph.Label.Native (for native canvas labels)
- Graph.Label.DOM(abstract class for dom elements)
- Graph.Label.HTML(extends the DOM interface with HTML specific stuff)
- Graph.Label.SVG(extends the DOM interface with SVG specific stuff)
I also modified the Canvas class so you can specify the type of labels you want to use, labels:'HTML', labels:'SVG' or labels:'Native'. Default's HTML.
The same RGraph example code now would look like this:
//Add the name of the node in the correponding label
//and a click handler to move the graph.
//This method is called once, on label creation.
onCreateLabel: function(domElement, node){
domElement.firstChild
.appendChild(document
.createTextNode(node.name));
domElement.onclick = function(){
rgraph.onClick(node.id, {
hideLabels: false
});
};
},
//Change some label dom properties.
//This method is called each time a label is plotted.
onPlaceLabel: function(domElement, node){
var bb = domElement.getBBox();
if(bb) {
//center the label
var x = domElement.getAttribute('x');
var y = domElement.getAttribute('y');
//get polar coordinates
var p = node.pos.getp(true);
//get angle in degrees
var pi = Math.PI;
var cond = (p.theta > pi/2 && p.theta < 3* pi /2);
if(cond) {
domElement.setAttribute('x', x - bb.width );
domElement.setAttribute('y', y - bb.height );
} else if(node.id == rgraph.root) {
domElement.setAttribute('x', x - bb.width/2);
}
var thetap = cond? p.theta + pi : p.theta;
domElement.setAttribute('transform', 'rotate('
+ thetap * 360 / (2 * pi) + ' ' + x + ' ' + y + ')');
}
This code does a little bit more than just plotting the label, it rotates the labels so they're not occluded:
Good points of this approach are:
- Just like with any other DOM element, you can add event handlers.
- You can apply transformations to labels.
Weak points:
- Performance, for the same reasons as HTML.
- IE does not support SVG.
Bonus good point: Google is making work SVG in IE with some open source library that works apparently the same as the ExCanvas library. Here's the Open Source project that will be presented here.
That's like the main reason why I've been considering a different approach for labels
Native Canvas labels
Native Canvas labels make use of the HTML5 Canvas text API to plot labels.
Since the labels are just painted in the Canvas there's no DOM tree to update, and performance is good.
The Canvas text API has fillText, strokeText and measureText as methods. You can read more about the Canvas Text API here.
This is the code I added to the Graph.Label.Native class:
Graph.Label.Native = new Class({
plotLabel: function(canvas, node, controller) {
var ctx = canvas.getCtx();
var coord = node.pos.getc(true);
ctx.fillText(node.name, coord.x, coord.y);
},
hideLabel: $empty
});
A very good point about this approach is performance. Also, the code is simpler. You don't have to keep a labelContainer and update DOM labels each time you're making an animation.
Weak points are:
- Opera does not support this feature.
- You can't natively add event handlers to labels. I think I've seen someone do something similar for text in processing, but I'm not sure there's a good way of doing this without keeping track of the position of each label and perform a check each time a click is triggered in the canvas element.
- I should change the way I define controller methods, in order to be able to pass a custom label object with x, y, theta, rho, width, height properties that could be modified on the fly, and then translate these changes into translate and rotate native canvas calls to be able to plot the text the way the user wants it. This seems just to damn complicated.... But I'll consider it.
Anyway, these are the methods I've found to plot labels into graphs.
Which one do you think is the best?
Do you know about any other approaches I could take to solve this problem?
Hello there, I'm Nicolas Garcia Belmonte, a Computer Science Engineer from the Buenos Aires Institute of Technology, in Argentina. I live in France now.
Great stuff. Of the three methods I prefer the SVG approach, because I think label events are crucial, and because of rotation being better supported than with html elements (especially given the Google library you mentioned). Giving the option for the user to decide would be great, as I can see how going native and losing the events for better performance would be prefered in some cases.
Is the only advantage of html elements over SVG the browser support?
There is an important difference between excanvas and svgweb: excanvas translates canvas commands to VML (Microsoft’s propriertary version of SVG) to compensate the lack of canvas in IE, whereas svgweb embeds a flash movie to display SVG in any browser.
About the event handlers: maybe there is the possibility to implement a “lazy” event handler, that calculates the label position only if the callback function tells him to do so.
Re: Native labels
You can optimise the search for what is clicked by dividing the canvas space into quarters, recursively, until there is only one clickable element in each quad.
I do something like this in a toy project I was working on;
a good starting point is here:
http://github.com/mcobden/CanvasGraphLib/blob/07a3133d0105f6ca3a7ddf4e841d115a08fcdf7c/src/tree/CanvasMouseEventTree.js
Here’s a some notes which might explain the odd way it appears to do thigns.
1) you need to limit the depth of recursive subdivision, to prevent nodes on the same point recusing infinitely
2) To find nodes which might have been clicked on, you traverse the quad tree till you arrive at a leaf quad, and then check the event relative to all the nodes in it.
3) nodes of non-zero size (the norm) must be treated differently; I store them in the smallest quad they fit without exceeding any of the boundaries (nb: may not be a leaf quad). On traversal to the leaf quad these nodes must also be added to the list of those to check.
4) Rebuilding the tree after moving anything is a pain. It may or may not be a work in progress. (I might not have comitted it to github)
This paper describes how this division can be used for optimising computation of repulsive forces in force-directed graph algorithms.
http://www.springerlink.com/content/mlbkplfwx7cmk4hf/
The non-zero sized node considerations are an adaption of this.
to clarify “(nb: may not be a leaf quad)” it meant “(nb: might not be a leaf quad)”
@Ollie: I don’t have any numbers to back up this, but I’ve “”felt”" that SVG perfomance was less good than html.
@Franz: Thanks for your reply, I knew that Adobe’s solution was to embed flash, I just thought that Google’s solution was going to translate things into VML. Somehow this might be impossible.
@Marcus: Thanks for your links, I didn’t know the quad tree could be a good approach for this. I’ll take a look at it