While browsing the internet I got to the Guardian’s Datablog, a blog that gathers interesting information and datasets to explore and make visualizations. Latest post was about Every Doctor Who villain since 1963. There’s information about each villain’s first and last year of appearance, their motivation/evil plan, the name of the actors who played the role of Doctor Who while that villain was making an appearance, the title of the stories where that villain was in, etc.
I created a “dynamic” TreeMap visualization with that data. Here’s a short screencast I made explaining the TreeMap functionalities (I have a horrible english accent… I know). You can also play with the demo here.
The Code
For this example I used a special build of the Toolkit which is currently hosted at GitHub. The TreeMap example code looks just like the TreeMap demos code but I also added an onBeforeCompute callback that checks for the Doctor Actor Name and Villain Motivation filters to fade nodes respectively:
The anchor click callbacks set the current selected value to the doctorName and motivation variables and also perform an animation by fading nodes and repositioning the remaining visible nodes:
The tm.compute(‘end’); call will trigger the onBeforeCompute callback that will set correct alpha values for the nodes. Then we perform an animation of node positions and node alpha, width and height properties.
The JavaScript InfoVis Toolkit provides web standard based tools to create interactive data visualizations for the Web.
What’s new in this version?
This version introduces radical new features, an API redesign and new visualizations. If you don’t want to read the whole article and just want to play with the examples you can go to the demos page.
New Visualizations
With this version of the Toolkit the number of available visualizations has doubled. Some of the new visualizations are the AreaChart, BarChart and PieChart, which were described in more detail in this article. I’ve also added Sunburst and Force-Directed visualizations. I wrote about these visualizations before here and here. I also want to thank Pablo Flouret, who contributed most of the code for the Icicle visualization, also a new addition to the toolkit.
You can play now with these visualizations at the demos page!
Features common to all visualizations
I’ve also enhanced all visualizations with new configuration options that enable new features. These features are:
Panning and zooming across all visualizations.
A new event system that enables you to attach events to DOM elements or to native canvas nodes and also add support for touch events, drag and drop, etc.
Complex animations have the ability to animate any style property of a node, edge or label. There is also support for animating canvas specific properties like shadowBlur, shadowColor, fillStyle, etc.
A new TreeMap visualization
The underlying rendering functions in the TreeMap visualization have changed. While in prior versions of the Toolkit the TreeMap was DOM-based, this new version renders the TreeMap entirely in Canvas. This enables you to add custom nodes of any shape or nature you like (can be images, circles, polygons) and also to take advantage of the new animation engine of the toolkit to add smooth transitions for the drill-down. These new things can be tested at the TreeMap section in the demos page.
API Redesign
The old API was too low level. Before creating any visualization you had to manually create a Canvas widget and pass it as parameter to the visualization class. Also, many other parameters like width and height of the canvas were required. For Background canvases the API had a couple of flaws, and it wasn’t clear how to use it either. Many of these things have been solved with the new API design. The Canvas class became an inner class implicitly created when making a new visualization. Width and height of the canvas are set to the container’s offsetWidth and offsetHeight if they’re not provided, and background canvases are easier to attach to the visualization.
Most of all, there is now a single global object in the library: $jit. This declares the namespace for the library and makes sure you won’t have conflicts with any other JavaScript library.
A new Website
Last but not least, I worked on a website redesign, taking advantage of the new HTML5/CSS3 features supported by major browsers. There’s also a detailed documentation page to get you started.
We’re not that far. Not at all. I was actually going to write some completion percentage, but I think I’ll just leave that as a mystery and surprise you when the time comes. But until then… some videos from the 2.0 world!
Animated TreeMaps
In order to show some of the new features I’ve been writing a simple example with TreeMap animations. TreeMap animations are integrated into the built-in classes of the Toolkit, but you can also create your own animations by altering either built-in Node/Edge params, or also canvas specific styles like shadows.
Here’s a short video of an Animated TreeMap, it also has animations when switching layouts. I think it’s better seen in fullscreen.
Zooming and Panning
The new Event system allows many customizations, such as Dragging and Dropping nodes, (right)clicking native Canvas nodes, etc. This will be the subject of a longer post, since there is a lot of machinery involving Native Canvas, SVG and HTML events, event delegation, etc. I’ve also been working in making a modular Canvas class enabling canvas background extensions.
Some of these changes had some desirable effects, such as enabling Panning and Zooming in a generic way, across all visualizations, as can be seen in this video:
A Force Directed Example
These features can be combined into useful and interesting examples. This Force Directed example uses the new Event system, zooming, panning and animations to make a complete graph editing tool. These are some of the graph interactions that can be made with the JavaScript InfoVis Toolkit (also better seen in fullscreen):
I hope you liked it. I know I’m having a great time working in this project.
Just a quick post to tell you that I’ve been invited to speak at YOW! Australia Developer Conference in Brisbane and Melbourne in December. YOW! is the new name for the JAOO (a.k.a Java and OO) conferences that have been running for over 13 years around the world already. YOW! Australia 2010 will include talks by Guy L. Steele, Jr., Erik Meijer and me among others -yes, I can’t believe I just put myself in the same list as these people!.
JavaScript animations are a key aspect of dynamic Web Sites and Application development. Moreover, most JavaScript Frameworks or Libraries provide APIs for dealing with at least three main things:
Advanced DOM manipulation
Ajax
Animations
When developing Web Sites most JavaScript effects involve rendered DOM Elements, but sometimes JavaScript animations are used in other contexts, like when using the Canvas. In the JavaScript InfoVis Toolkit the main target of my animations are Graphs, and in the next version also Nodes and Edges as separate entities.
Today I’d like to describe how to create a generic animation class that can be used or extended for any purpose. I’ll try to be minimalistic and to present only the needed code for making animations. Then you might find useful to add some code to perform specific animation tasks targeting for example specific style properties of a DOM Element.
Defining an Animation Class
Before creating an Animation class we might want to consider what to expose as options to the user. The options I thought of are:
The duration of the animation (in milliseconds)
The frames per second of the animation
Additionally we’d like to add a couple of controllers, one when a step of the animation is executed and one when the animation has completed:
delta gives us an idea of the progress of the animation. When the animation starts delta will be equal to zero. When the animation ends it’ll be equal to one.
We will also need a start method to trigger the animation and a step method that will compute delta at each step.
Now that we defined our options we can start thinking about our implementation.
Implementing the Animation class
Our Animation class will be a class constructor that sets all the options and properties that we defined before and a prototype with the methods start and step. The class could be used like this:
var fx = new Effect({
duration: 1000,
fps: 40,
onStep: function(delta) {
/* do stuff */
},
onComplete: function() {
alert('done!');
}
});
//start the animation
fx.start();
Here’s the code I came up with, inspired by the MooTools Framework:
//define the class constructor
function Effect(opt) {
this.opt = {
duration: opt.duration || 1000,
fps: opt.fps || 40,
onStep: opt.onStep || function(){},
onComplete: opt.onComplete || function(){}
};
}
Effect.prototype = {
//define how the animation starts
start: function() {
//return if we're currently performing an animation
if(this.timer) return;
//trigger the animation
var that = this, fps = this.opt.fps;
this.time = +new Date;
this.timer = setInterval(function() { that.step(); },
Math.round(1000/fps));
},
//triggered at each interval step
step: function() {
var currentTime = +new Date, time = this.time, opt = this.opt;
//check if the time interval already exceeds the duration
if(currentTime < time + opt.duration) {
//if not, calculate our animation progress
var delta = (currentTime - time) / opt.duration;
opt.onStep(delta);
} else {
//we already exceeded the duration, stop the effect
//and call the onComplete callback
this.timer = clearInterval(this.timer);
opt.onStep(1);
opt.onComplete();
}
}
};
One very common operation to do with delta is to change the interval [0, 1] of delta to our desired from and to values that we want to compute for our element. A clever thing to do would be to declare this method as a class method for Effect. We'll call it compute:
Effect.compute = function(from, to, delta) {
return from + (to - from) * delta;
};
Now If we wanted for example to animate an element's width style from 0 to 10px we could do:
var elem = document.getElementById("myElementId"),
style = elem.style;
var fx = new Effect({
duration: 500,
onStep: function(delta) {
style.width = Effect.compute(0, 10, delta) + 'px';
}
});
fx.start();
Extending the Effect class
The animation code defined above could be extended in different ways. For example, this class could be slightly modified to accept a DOM element in its constructor and modify style properties of that element when performing an animation. The code could look like this:
var elem = document.getElementById("myElementId");
var fx = new Effect({
element: elem,
duration: 1000
});
fx.start({
'width': [0, 20, 'px'],
'height': [0, 5, 'em']
});
The code would now look more or less like this:
//define the class constructor
function Effect(opt) {
this.opt = {
element: opt.element,
duration: opt.duration || 1000,
fps: opt.fps || 40,
onComplete: opt.onComplete || function(){}
};
}
Effect.prototype = {
//props contains a hash with style properties
start: function(props) {
if(this.timer) return;
var that = this, fps = this.opt.fps;
this.time = +new Date;
this.timer = setInterval(function() { that.step(props); },
Math.round(1000/fps));
},
//triggered at each interval step
step: function(props) {
var currentTime = +new Date, time = this.time, opt = this.opt;
if(currentTime < time + opt.duration) {
var delta = (currentTime - time) / opt.duration;
//set the element style properties
this.setProps(opt.element, props, delta);
} else {
this.timer = clearInterval(this.timer);
this.setProps(opt.element, props, 1);
opt.onComplete();
}
},
//set style properties. Properties must be
//in camelcase format.
setProps: function(elem, props, delta) {
var style = elem.style;
for(var prop in props) {
var values = props[prop];
style[prop] = Effect.compute(values[0], values[1], delta)
+ (values[2] || '');
}
}
};
Other extensions might involve normalizing style keywords, adding effect transitions, adding pauseresume methods, and/or using more OO JS idioms when coding these classes.
I hope you got to know a little bit more about animation internals and please if you have any advice on this code, which as I told before is just for demonstration, I'll be pleased to hear you!
This is going to be the first of a couple of posts related to Voronoi Tessellations, Centroidal Voronoi Tessellations and Voronoi TreeMaps. In this post I’ll explain what a Voronoi Tessellation is, what can it be used for, and also I’ll describe an interesting algorithm for creating a Voronoi Tessellation given a set of points (or sites as I’ll call them from now on).
What is a Voronoi Tessellation?
Given a set P := {p1, …, pn} of sites, a Voronoi Tessellation is a subdivision of the space into n cells, one for each site in P, with the property that a point q lies in the cell corresponding to a site pi iff d(pi, q) < d(pj, q) for i distinct from j. The segments in a Voronoi Tessellation correspond to all points in the plane equidistant to the two nearest sites.
Voronoi Tessellations have applications in computer science, chemistry, etc. but I’m most interested in Voronoi Diagrams for constructing Voronoi TreeMaps (more on that in later posts).
How do I create a Voronoi Tessellation?
One algorithm for creating Voronoi Tessellations was discovered by Steven Fortune in 1986.
This algorithm is described as a plane sweep algorithm. Fortune’s Algorithm maintains both a sweep line (in red) and a beach line (in black) which move through the plane as the algorithm progresses.
The structures used in this algorithm are an EventQueue, EdgeList and a binary Tree that tracks the state of the beach line.
The EventQueue stores two distinct type of events that are related to changes in the beach line. These events happen when:
A site s crosses the sweep line: in this case a new parabola with minimum at s is added to the beach line. A Voronoi Edge is born.
A circle that touches three sites staying behind the sweep line is found and is tangent to the sweep line (see image below). A Voronoi Vertex is found.
At each of these stages the EdgeList is updated until the algorithm is completed.
Implementations
I haven’t found any interesting implementation of this algorithm in JavaScript. Actually, I didn’t find a working implementation of this algorithm in JavaScript. There’s this version of a JavaScript applet for making Voronoi Tessellations, but it doesn’t seem to work right (the corners of the image generally hold two or more sites in the same cell). Also, the code was based in a C# implementation and isn’t very pretty. Then there’s this blog that mentions the algorithm but there’s no visible implementation, just a JQuery demo that animates parabolas when a mouse crosses a site, but no Voronoi Diagram.
So I made my own implementation, which I tried to make as similar as possible to the original C implementation from Steven Fortune. If you click on the image you can see it in action. Just refresh the page for new Voronoi Tessellations of random positioned sites.
Any comments or advices about how to make this implementation better are welcomed!
I like to see language implementors (or creators in this case) talk about the design challenges or choices they’re facing with in the next version of their languages.
In this video Brendan Eich, the creator of JavaScript, talks about the ES 3.1/4/5 thingy and also explains what features will be added to JavaScript in some near future (at least for the ECMA standard).
I’ll add a couple of comments about the JS features I liked below the video.
New stuff I liked about the language
Most of the things I liked about the new features of the language are related to Meta-Programming. These new features describe new behaviors in object properties, like getters and setters, but they are also related to object and property mutability, configuration, visibility, etc.
Getters and Setters
Getters and Setters were implemented by B.E. more than nine years ago at mozilla, but a new syntax is introduced in the standard by adding a static function to the Object class.
In this example the defineProperty static method of the Object class adds the length property to the obj object. The get and set methods will be called when accessing or modifying the length property. Object.getOwnPropertyDescriptor retrieves the property descriptor of the defined property.
Defining Methods and Richer Property Descriptors
The Object.defineProperty method can also be used to define instance methods:
If configurable=true, the property will be enabled for deletion or to be changed in other ways.
You can set a property to be non-enumerable by setting enumerable=false, and it won’t be detected in a for in loop (or in any other “prop” in obj expression). This means that for example we could augment Object.prototype with methods without having to iterate through them in a for in loop.
The writable property if setted to false won’t allow you to change the value of that property.
Object.create
Still no support is added for classical inheritance patterns (which makes me happy I must confess).
Instead, the differential inheritance pattern gets a function that had (somewhat) been implemented by frameworks like Closure, MooTools and others with the inherits and $merge functions. Object.create can be used for implementing prototypical inheritance: you can create a new class A that inherits from B by cloning an object and augmenting it with a Properties object. For example:
var Person = function() {};
Person.prototype.eat = function() {
alert("eating");
};
//Ninja extends Person
var Ninja = function() {};
Ninja.prototype = Object.create(Person.prototype, {
doKungFu: function() {
alert("wootoo");
}
});
var n = new Ninja();
n.eat(); //eating
n.doKungFu(); //wootoo
However, don’t forget to instantiate the superclass in your subclass constructor:
Mutability is nice but sometimes we need to make our objects immutable for design reasons, for security reasons. These methods change the mutability level of an object.
Object.preventExtensions prevents an object from extending (i.e adding new properties to it). Still the properties it has can be deleted and their value can be changed.
Object.seal does everything Object.preventExtensions does and also sets configurable=false for its properties, so they can’t be deleted. The Object properties can be changed though.
Object.freeze makes the object completely immutable. Object.freeze does the same Object.preventExtensions and Object.seal do but also sets writable=false for all object properties.
I hope this was useful to you. There are a lot more interesting language features to come, so you can read the ECMA draft if you’re interested in knowing more about this new version.
A Sunburst visualization is a radial space-filling visualization technique for displaying tree like structures. There are other space-filling visualization methods that use other visual encodings for describing hierarchies. For example, the Treemap is a space-filling visualization that uses “containment” to show “parent-child” relationships.
There are a couple of subtle changes that can improve the way the information is communicated by this visualization.
The “classic” Sunburst visualization uses horizontal labels for node names. One problem with this is that as I mentioned in a previous post labels can be occluded. One solution for this is to rotate labels in a way that they’re not occluded.
A simple yet important thing to do when rotating labels is to rotate the labels in a way that they’re always facing up.
In this example some labels are upside-down:
A simple check could make labels more readable:
Another interesting thing that can be used with the Canvas Text API is the maxWidth parameter. This is an optional parameter that can be used to try to force the text to fit some width. I use this parameter when plotting the Sunburst visualization:
Node Styling and Behavior
The visualization also implements events for hovering and clicking nodes. You can also provide any number of styles to be smoothly updated when hovering and clicking nodes. There’s also onClick and onHover callbacks that are called when a node is clicked or hovered respectively.
For example, this is the configuration I used in the previous example:
Node styling and tool-tips can be attached to DOM elements (like HTML or SVG labels) or they can also be attached to the Canvas. The latter method uses an internal MouseEventManager to calculate the position of the mouse event and determine which node of the graph is being hovered or clicked.
Collapsing and Expanding Subtrees
I’ve been also implementing animations for collpasing/expanding subtrees:
The collapsing process reduces the angle span occupied by a parent node and sets its children alpha value to zero. There’s also a visual mark set for collapsed nodes.
I hope you like this visualization. There’s still much work to do, mostly regarding browser compatibility. I’ll keep you up to date with the progress of this visualization and the next visualization I’ll be implementing in the next post
I’m currently working on three new visualizations for the JavaScript InfoVis Toolkit that will be added in version 1.2.
I started the development of these new visualizations a couple of weeks ago, and while trying to incorporate these new visualizations harmoniously into the Toolkit I’ve found myself considering new design and code abstractions I haven’t thought about before. That’s good for the Toolkit, and also good for my brain
One of the visualizations I’ll be incorporating in the next major release is a Force-Directed visualization. I first want to thank Marcus Cobden for donating a lot of code related to this algorithm that you can find here.
My code is based in his donation and also in a nice overview of Force-Directed layout algorithms that I’ve found here.
So what are Force-Directed Layout Algorithms?
Force-Directed Layout algorithms are graph drawing algorithms based only on information contained within the structure of the graph itself rather than relying on contextual information. The most straightforward Force-Directed algorithm uses repulsive forces between nodes and attractive forces between adjacent nodes. This physical model produces some local minima in which the graph, well, gets to a stable configuration and is drawn in an aesthetically pleasing way.
The main algorithm consists on a main loop that simulates the system for some iterations and then plots the graph. The system will consist on repulsive forces between all graph nodes and attractive forces between adjacent nodes. The force models considered correspond to Hooke’s law and Coulomb’s law.
Here’s an example with some JSON data I also use for other examples at the demos page:
There are lots of refinements and different methods for making Force-Directed Layouts. Some are just based on the model I described before, others are based on what’s called Graph Theoretic Distances: If for two adjacent nodes their ideal distance is set as d, then for nodes with shortest path distance of n their ideal layout distance should be n * d. Attractive and repulsive forces are used to make a graph system with random nodes positions get to a local minima based on these rules.
I implemented the first model I described. For each iteration the computePositionStep method is called to update all nodes positions based on attractive and repulsive forces. The formal parameters passed to the method are property which is an array of node properties which contain positions to be updated and opt which is an object containing layout options like generic repulsive and attractive force functions. $C creates a new Complex Number.
computePositionStep: function(property, opt) {
var graph = this.graph, GUtil = Graph.Util;
var min = Math.min, max = Math.max;
var dpos = $C(0, 0);
//calculate repulsive forces
GUtil.eachNode(graph, function(v) {
//initialize disp
$each(property, function(p) {
v.disp[p].x = 0; v.disp[p].y = 0;
});
GUtil.eachNode(graph, function(u) {
if(u.id != v.id) {
$each(property, function(p) {
var vp = v.getPos(p), up = u.getPos(p);
dpos.x = vp.x - up.x;
dpos.y = vp.y - up.y;
var norm = dpos.norm() || 1;
v.disp[p].$add(dpos
.$scale(opt.nodef(norm) / norm));
});
}
});
});
//calculate attractive forces
var T = !!graph.getNode(this.root).visited;
GUtil.eachNode(graph, function(node) {
GUtil.eachAdjacency(node, function(adj) {
var nodeTo = adj.nodeTo;
if(!!nodeTo.visited === T) {
$each(property, function(p) {
var vp = node.getPos(p), up = nodeTo.getPos(p);
dpos.x = vp.x - up.x;
dpos.y = vp.y - up.y;
var norm = dpos.norm() || 1;
node.disp[p].$add(dpos.$scale(-opt.edgef(norm) / norm));
nodeTo.disp[p].$add(dpos.$scale(-1));
});
}
});
node.visited = !T;
});
//arrange positions to fit the canvas
var t = opt.t, w2 = opt.width / 2, h2 = opt.height / 2;
GUtil.eachNode(graph, function(u) {
$each(property, function(p) {
var disp = u.disp[p];
var norm = disp.norm() || 1;
var p = u.getPos(p);
p.$add($C(disp.x * min(Math.abs(disp.x), t) / norm,
disp.y * min(Math.abs(disp.y), t) / norm));
p.x = min(w2, max(-w2, p.x));
p.y = min(h2, max(-h2, p.y));
});
});
}
You can find more information about this algorithm in this overview of Force-Directed algorithms.
This method is called multiple times to provide a final layout, for example like this:
Where times corresponds to the number of iterations of the simulation, and is generally > 50 and t can be thought as the global temperature of a system that gets cooler with each iteration.
Performance
Although there are a couple of methods to reduce the complexity of this algorithm, this implementation runs like O(V^3), which can be considered as really bad performance.
This is not desirable for real-time interactive visualizations, in which everlasting computation algorithms can lead to blocking browser popups like “This Script is Taking too long…” or things like that.
One way you can avoid these popups is by making incremental computations. This can be done by splitting the main algorithm that has for example 100 iterations into smaller pieces of 20 iterations each. The main iteration loop could then be changed into something like this:
And the main computation would be split into smaller parts calling on each step of the computation the onStep callback.
Graph Operations
For graph operations (Adding/Removing nodes and edges, Graph Sum and Graph Morphing) I make all iterations in the first layout and then only apply 20 iterations after some operation has been completed. Here's a video:
When (*not*) to use Force-Directed Layouts
Force-Directed Layouts can be a good choice when you're drawing general graphs and you don't have domain specific (or any other topological) information about them.
Tree structures however are a special case of graphs: this means that tree structures have more constrains and therefore there's more contextual information for drawing a Tree than for drawing a general graph.
Also, Trees are easier to grasp for the human eye than "general graphs". There's that intrinsic notion of hierarchy that can be used to draw aesthetically pleasing graph layouts. Think about the "general graph" layouts that start with the drawing of a spanning tree and then add the "extra edges" to complete the graph structure (for example here and here). The Multitrees method I mentioned a couple of posts ago was also developed to try to extract more contextual information about a graph and draw it based on a notion of partial hierarchy.
Because of this, in my opinion, it wouldn't be wise to plot Trees that have many nodes with this Force-Directed algorithm: this extra-information about trees isn't used in this layout. However, if you're planning on drawing general graphs and you don't have any other information about them, then this algorithm can detect interesting symmetries and make aesthetically pleasing drawings.
I'll keep you updated with the other visualizations I'm working on in the next posts.
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.
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.