A graphical toolkit for visualization


API Documentation



Release Notes


Property Chaining
Local Variables


Getting Started
Scatterplot Matrix
Scale Interaction


IEEE InfoVis 2009

Language Manifesto

Many graphics libraries exist for drawing shapes and manipulating pixels. These are often easy-to-learn and compatible with “visual thinking”: they provide a direct way to draw curves, polygons, and other visual elements. Yet if used for visualization, these low-level interfaces can be tedious due to the lack of common abstractions, such as scales for color and position.

At the other end of the spectrum, many visualization libraries allow the concise expression of charts and visual encodings. Some even allow fully-customizable, interactive design. Yet while these tools make certain tasks easy, they often relinquish direct control over the rendered marks. Furthermore, the implicit, top-down approach can be difficult to grasp and impede visual design.

Our goal with Protovis is to find a middle ground that offers some of the benefits of both types of system. Protovis is a graphical toolkit, designed for visualization. It retains some of the conceptual simplicity and low-level control of graphical systems by dealing directly with graphical elements (shapes, lines, i.e., marks), but specifies marks declaratively as encodings of data. Additionally, we provide useful abstractions such as scales and layouts to simplify common tasks.

Declarative and Data-Driven

Protovis is similar to other graphics libraries such as Java 2D or Processing: we provide a mechanism for drawing rectangles (bars), circles (dots), lines, and polygons (areas). However, Protovis uses a declarative, rather than imperative, syntax. Consider, for example, how this representation affects a pie chart specification.

In Processing, you might specify a pie chart as series of arcs using a for loop and a call to arc, which immediately draws a single arc to the canvas:

for (int i = 0; i < data.length; i++) {
  fill(data[i] * 120);
  float ang = data[i] / sum * 2 * PI;
  arc(75, 75, 140, 140, lastAng, lastAng + ang);
  lastAng += ang;

In Protovis, you almost never use a for loop. A set of related graphical elements, such as the arcs in a pie chart, are specified as a single mark. The mark is associated with data, and the properties are specified as functions, encoding the data graphically:

    .angle(pv.Scale.linear(0, pv.sum(data)).range(0, 2 * Math.PI));

Note that in Processing, you have to increment the start angle (lastAng) by hand. In Protovis, the angle encoding is specified as a function: a linear scale. The start angle is automatically the previous wedge's end angle, so no bookkeeping is necessary. The declarative syntax allows for many such conveniences:

Inheritance - New marks can be added to a visualization that inherit properties from existing marks. This allows encodings to be reused, and eliminates code duplication. In addition, it provides the basis for some of the more advanced tools, such as standard layouts (e.g., treemaps).

Property Chaining - One mark's properties can be defined in terms of another mark's properties. For example, say you wrote a complicated function to compute a mark's fill color. If you want the stroke color to be the same, but translucent, you can define it as this.fillStyle().alpha(.4). This technique can also be used to position related marks and annotations, as with anchors.

Smart Properties - Because related graphical elements are expressed as a single mark, with properties derived from data, smart defaults are possible, as shown above with the wedge start angle. Another example is default categorical colors for fill and stroke. Even better, we can write reusable property functions, such as scales.

Interaction and Animation - A mark is not just a command to color some pixels, but a description of the visualization's structure. This means you can associate event handlers with marks, much like you can with parts of a web page. In addition, when the visualization is updated for animation, Protovis can redraw efficiently. In the future, we'll also support smoothly-animated transitions.

Copyright 2010 Stanford Visualization Group