Abstract
This paper discusses how SVG is used in different visualization efforts at Oracle.
In a first section, the paper discusses the use of SVG as an export format for business graphics, as well as the use of SVG as an import format for inserting custom graphics into visualizations. This first section presents the advantages of using SVG, discusses the issues met and shows examples of SVG's usage in Oracle's ADF visualization components, the Data Visualization Tools components (DVT).
In a second section the paper presents how SVG can be leveraged for animated, interactive visualization components to provide features as rich as competing technologies. For example, animation effects on interactive user interface elements are demonstrated. That section also discusses the advantages SVG brings as well as some of the limitations in current implementations (e.g., around font metrics and text bounds) or in the format (e.g., the ability to target multiple elements with the same animation or the ability to hook scripts to the animation engine) and thoughts on how some new features (such as the combination of the Canvas API and SVG) might provide an improved platform.
Table of Contents
Oracle ADF Faces is an application development framework that extends JavaServer Faces and provides over 150 Ajax-enabled components for building rich Java EE applications. These components include everything from buttons and menus to progress indicators and tables.
ADF Faces also includes a set of components used for looking at business data. The ADF Data Visualization Components include a variety of graphs and gauges, a pivot table, Gantt chart, hierarchy viewer, and mapping components. As graphical business visualizations, the graph and gauge leverage SVG as an output format as well as an input format.
The graph and gauge components are designed to support several different rendering formats. There are two stages involved in creating the final output, a layout/calculation stage and a rendering stage. In the first stage, the API settings are processed, and the geometries are calculated and stored in Java shape objects. Along with their fill and border properties, these shapes are stored in a list of objects to be drawn. In the second stage, this list of objects is passed to one of several renderers for export into the desired rendering format, such as PNG, Flash, or SVG.
This process flow allows our customers to take advantage of the benefits of each image format. With SVG, our users get scalable, standards based graphics that render without plugins in browsers such as Firefox, Safari, and Chrome. In PDF reports, SVG provides for clarity and proper layout at any size, especially for text. SVG also allows for efficient and accurate printing, since it is a vector graphics format.
Another use of SVG is in the custom graphics feature for the gauge component. Over the years, there have been many requests for graphical styles that were different from the default gauge. While the user could always specify the colors and gradients on the gauge, the shapes and geometries were not customizable. As a component development team focused on creating reusable building blocks for applications, it's not efficient for us to create all of these graphical variations for the gauge. Instead, we implemented a feature that allows the application to specify the graphics directly, using SVG as the input format.
There were four main requirements that led to the choice of SVG as the input format. First, the custom graphics specification should be easy enough to use that artists can provide the graphics directly, ideally without the help of a developer. Second, there must be some way to identify the objects in the custom graphics definition as specific elements in the gauge. For example, the indicator needle in the graphics definition must be identifiable by the gauge so that it can be properly positioned and rotated. Third, the custom graphics must be supported in any of the rendering formats that the gauge supports. Finally, the custom graphics must be easily resized and rotated.
Given these requirements, SVG was clearly the best choice. A W3C recommendation, SVG can be directly exported using many of the popular vector graphics editors making it easy for artists to create the custom graphics. To identify subcomponents in the gauge, the id attribute of the SVG graphics elements is set to some predefined constants, such as id=”plotArea”. This sort of metadata is easy to add since SVG is XML based, and would not have been possible with an image format such as PNG. In order to support all of the gauge’s output formats, the SVG graphics are parsed during the layout stage of the gauge rendering and converted into the same Java shape definitions as the built in graphics. When passed to the gauge renderers, the custom graphics are indistinguishable from the default graphics and can be displayed in any of the supported formats. This is all possible only because the SVG specification is public and well defined. This leaves just the last requirement, which is fulfilled by the definition of SVG. As scalable vector graphics, SVG doesn’t lose fidelity when rescaled and can be easily rotated and transformed.
The following code snippet shows a simple SVG file used to customize the gauge frame, indicator, and indicator base of a dial gauge. In order to identify the indicator subcomponent of the gauge being customized, id="indicator" is set on the path element. The gauge will parse this id and process its graphics as the indicator. Other subcomponents have different ids. A nice benefit of this feature is that graphics definitions do not need to define a complete gauge. As in this example, partial definitions are fully supported, and allow for a quick and easy way to customize the gauge.
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<svg xmlns:svg="http://www.w3.org/2000/svg"
xmlns="http://www.w3.org/2000/svg"
version="1.0">
<rect width="264.72726" height="179.18887"
rx="8.2879562" ry="10.368411" x="2.76225" y="2.13995"
fill="#888888"
id="gaugeFrame"/>
<rect width="241.79999" height="120.13961"
x="14.2415" y="15.94714"
fill="#ffeeaa" fill-opacity="0"
id="plotAreaBounds"/>
<rect width="6.0830183" height="98.849045"
rx="2.6630435" ry="2.2987804" x="132.86035" y="37.23772"
fill="#276DFF"
id="indicator"/>
<rect width="74.516975" height="44.101883"
rx="2.6630435" ry="3.5365853" x="97.883" y="125.4415"
fill="#CCCCCC"
id="indicatorBase" />
</svg>
Besides its features leveraged for input and output, SVG also supports rich interactivity which could be leveraged for business graphics.
The SVG features provide some excellent benefits. There are also some areas which could be improved to help make SVG an even better environment for developing business graphics.
One of the important features of SVG is that it is aligned with all the other Web technologies. For any Web developer, working with SVG is a fairly natural transition where the XML markup, DOM Model, DOM Event Model are all familiar. The learning curve is in the SVG rendering model, the types of graphics it can render, and, for the most advanced cases, features such as filter effects and animation. But it is easy to get started and we find that developers can quickly get productive on SVG.
For example, the following visualization was created by a developer who had little SVG experience and a lot of HTML experience. The visualization was enhanced for this paper to demonstrate features discussed later on.
Native browser support makes SVG a viable solution for graphics which would otherwise be impossible to support.
There are cases (such as sparklines), where a large number of business graphics have to be displayed in an HTML table, for example. In these cases, it is not possible to rely on a browser plug-in technology because these typically do not scale to a large number of instances. SVG being natively supported in many browsers, it can, like Canvas, be used in such situations.
In addition, SVG is supported on Mobile devices such as the iPhone whereas competing technologies such as Flash are not.
Overall, we find that there is a good interoperability between implementations. All the core graphics primitives (basic shapes, Bezier curves, images, text) render the same, transforms are honored consistently and styling works according to the specification. There are glitches around the more sophisticated DOM features (e.g., text metrics metioned later) and implementation completeness (e.g., filter effects). However, the differences are minor and the interoperability is, all things considered, providing a solid platform for the type of graphics needed in our environment.
The following figure shows the visualization shown earlier rendered in three different SVG viewers.
Debugging is pretty easy in most browsers. At least, the debugging of SVG scripts is at the same level as it is for HTML based Ajax applications. Debuggers such as Firebug provide a fair debugging environment. Developers find support for variable watch, step debugging and profiling. This is a rich development environment, although not quite at parity with development environments for languages such as Java (e.g., JDeveloper, NetBeans, Eclipse) or C++. Note that this comparison reflects on JavaScript more than on SVG itself.
SVG offers the features needed for developing advanced, interactive business graphics. Combined with the dynamic nature of JavaScript language, it creates an environment where rich graphics features can be expressed concisely.
The following features are obvious but still core to business graphics:
-
Geometry (basic and complex shapes)
SVG's rich set of transformations and geometry object provide the flexibility to use the appropriate type of shapes where needed, from simple rectangular marker, to polygons, to arbitrary graphical shapes with Bezier curves. In addition, the DOM APIs provides a rich set of APIs to manipulate geometry objects, with very advanced features such as an API to find the coordinates of a point at a given length along a path.
The associated rendering model provides a solution for 'pixel perfect' rendering, making sure that graphics are rendered with high fidelity, and high resolution, either on screen or for printing, as described in the first section.
-
DOM Events
DOM Events, as in other Ajax applications, provide a rich foundation for eventing. The only missing feature is common support for CustomEvents which are key to application development, allowing applications to create and dispatch semantically rich events.
It is easy to create JavaScript helper methods to create and initialize graphical shapes with a simple JSON object circumventing the DOM API's verbosity. Likewise, JavaScript's dynamic features make it easy to bind data to graphical elements.
var svgElement = ...;
var attributesBag = {
"fill": "red",
"stroke-width": "4",
"stroke": "rgb(255, 255, 0)",
/* more attributes ... */
};
setAttributesOnElement(attributesBag, svgElement);
function setAttributesOnElement (attributes, element) {
for (var p in attributes) {
if (attributes.hasOwnProperty(p)) {
element.setAttribute(p, attributes[p]);
}
}
}
The following treemap example illustrates the use of DOM Events (for displaying tooltip information), linking (to open a URL on click) and very basic shapes (rectangles and rounded rectangles) and text.
As mentioned before, the ability to have high fidelity rendering is important in the business graphics worflows. SVG provides this high fidelity because the specification defines clear requirements for rendering and implementations following them. There are a few problems (such as pixel snapping mentioned later), but these appear for on-screen rendering and not at print resolutions. Besides, these issues can be circumvented.
For example, the following tree layout example (see next figure) provides interactive features. The different tree nodes and branches have interactive and animation features. For example, there is a subtle grow/contract effect on the expansion/collapse buttons and there are fade in fade out effects when the nodes expand or collapse. This rendering can be output into a static SVG rendering and provide a pixel-perfect rendering of what uses see on-screen, client-side.
One seamingly minor issue turns out to be a major one for business graphics. In SVG, even though the specification provides guidelines for letting implementations snap straight lines to the pixel grid, it seems that most of them do not implement that feature. As a consequence, a line drawn between coordinates (10, 10) and (100, 10), which a stroke thickness of 1 pixel, may be drawn fuzzy because it overlaps the rows of pixels above and below the line's geometry. The SVG specification provides hints such as 'shape-rendering', but unfortunately, this hint is often honored by turning off anti-aliasing. However, what is needed is a half pixel bias to make the stroked outline fit into the pixel grid.
This problem is found on other platforms, such as Silverlight. There are ways to circumvent these problems, but they involve costly computations and maintenance of the rendering tree.
There are some inconsistencies between the implementation of bounding boxes on text elements. In particular, some implementations compute the visual bounds of the text element instead of accounting for the whole glyph cell as mandated by the SVG specification.
The following figure shows the bounding box of a text element rendered in red for two different implementations. The top box is incorrect and the bottom one is correct.
By "offscreen" rendering, we mean the ability to specify that a portion of a tree is 'static' and should be turned into a static image. Ideally, there should be an ability to turn a portion of an SVG graphics into an image abstraction which could be then attached to an image element. We believe this would yield a great deal of flexibility to application developers, help improve performance (by reducing the number of objects held in memory) and enable new effects (e.g., recursively applying a filter effect to a graphic, even though this example belongs more to the music player space than to that of business intelligence).
This section discusses features that would make it easier to write advanced business visualizations in SVG, or would make these applications more performant.
The SVG rendering model assumes a fixed positioning for elements in their container (e.g., a group). However, it is often needed to layout elements in a consistent way, with specific alignment or spacing constraints. It would be useful to be able to subject structure elements to a layout. By default, the layout would not do anything and just leave the elements in their natural position. However, a flow layout, for example, could compute the bounding boxes of the elements, use that information to position them horizontally, and honor alignment properties.
Currently, the SVG DOM attribute updates are done piecemeal with the setAttribute(NS) method calls. There are two issues with this. First, it is pretty verbose and difficult to read. Second, it is not very efficient because it requires multiple back and forth between the application and the SVG engine. The work by the SVG Woking group in this area seems very much in-line with the type of APIs we use internally and we are hoping they get finalized and implemented in browsers.
As discussed before, the issue of snapping lines to the pixel grid is critical for on-screen display of business graphics. The shape-rendering attribute is not enough because it does not provide predictable or visually pleasing results. It would be good to add an rendering control attribute to shape elements that would allow precise control over that feature, for example with a stroke bias, similar to what is available in the Java 2D API.
The SMIL animation model provide a way to specify how an attribute value should be modified over time. The animation and timing model described in the SMIL specification are quite powerful. However, we find they lack in the ability to let the result of the computed animation value to apply to multiple targets instead of just one. For example, if multiple graphical objects need to fade out together, it would be useful to make all of them the target of the same animation on the opacity attribute. This would reduce the number of animation instances applications need to create.
In business graphics, filter effects are used with restraint. However, drop shadows are very common. Drop shadows require a filter area computed from the size of the filtered object. Therefore the objectBoundingBox coordinate system is used for the filter. However, the space needed to accomodate for the drop shadow's filter size (for a box filter or a gaussian blur) is independant of the filtered object but dependant on the filter size. For example, if we try to filter an object which is 20 by 20 and apply a box filter which is 6 by 6, the filter area should be 26 by 26. Turned into objectBoundingBox, this is 130% by 130%. However, if we want to apply the same filter effect to an object that is 200 by 200, then the ideal filter areay should be 206 by 206, which is 103% by 103% in objectBoundingBox space. Ideally, the filter element should allow the specification of filter area "margins" so that the filter area could be specifiyed in objectBoundingBox space and the filter margins in a different space. As a result, the width of the filter area could be made to be 100% of the object bounding box's width plus the size of the convolution box (or that of the gaussian blur kernel). This way, the same filter could be used on objects of different sizes.
There are situations where it might be useful to perform certain animations that require computiations not easily expressed with the predefined animation elements. For example, one might want to position an element in the middle of two other animating elements. It would be great if there was an extensibility mechanism for SVG animations to call a script every time the animation tree is computed by the animation engine.
Some types of graphics are easier to create with an immediate mode rendering API. It would be really handy to be able to specify a custom element and defines its rendering in terms of the Canvas API. An example of this was given in the previous section.
The implementation of ProgressEvent,
specified
in the SVG Tiny 1.2 recommendation, will let
applications track the loading progress of images (or other
resources), which is not currently possible.
SVG is a rich graphics platform that can be used in different ways. As an rendering format, it provides a rich set of graphics primitives, useful structure (it is easy to group graphical elements, add descriptions or meta-data) and high fidelity rendering. These features are leveraged by ADF components for exporting business graphics and to customize visualizations such as Gauges.
Like HTML content, SVG content can be manipulated by Ajax scripts. SVG provides a host of rich interactive features, which form a strong base for interactive business graphics that can integrate nicely in an HTML context.
Since browser support keeps improving as it has in the recent years, SVG seems to be a good solution for highly interactive business graphics. It should get even better when combined with new features such as the SVG 3D Transforms or the CSS 3D transform work. Hopefully, user requested items, such as the ones shown in the "wish list" section, will be taken into account by the SVG Working Group to keep improving the format, and by implementors in chosing their next development efforts.