Improving the Performance of Dynamic SVG

Rhodes Brown
Department of Computer Science
P.O. Box 3055, STN CSC
Victoria, BC, Canada V8W 3P6


The dynamic aspects of SVG (scripting in particular) offer developers an opportunity to create portable, interactive user interfaces that blur the lines between document and application. In this sense, SVG can be leveraged to decouple the graphical interface of an application from its underlying logical operation, allowing the two aspects to vary independently. However, one significant barrier to adopting SVG as a standard for constructing application interfaces is the complicated, and often slow mechanism required to process user events.

Full support of SVG's scripting capabilities essentially requires an implementation of the XML Document Object Model (DOM), or minimally, a simulation of the DOM that supports SVG elements. While a DOM provides a structured representation of an XML document, the structural elements are still quite generic and attribute values are treated uniformly as text. Such a model is often an inefficient representation of the underlying data, and thus many applications implement a second, parallel structure that mirrors the DOM using specialized data elements. This approach is often referred to as data binding. For example, the Batik SVG library [1] uses a parallel DOM representation call a GVT tree, which builds on the standard JavaTM graphics API.

Dynamic SVG Bottlenecks

Figure 1 - SVG Event Processing

Processing a user interface (UI) event under the SVG model involves a number of steps which are illustrated in Figure 1. An event is intercepted by the underlying UI manager (eg. windowing system) and (1) dispatched to the GUI model. In most cases an event will trigger the execution of a script function which requires locating the code by inspecting the DOM (2), and then forwarding the code to a script interpreter (3). The interpreter must, at the very least, parse the incoming code and may also inspect the DOM to obtain various data values. The effect of a script often changes DOM elements (4). In most cases only attribute values are affected, but some changes may actually restructure the DOM itself. The changes in the DOM must then be communicated to the parallel data representation (5). Finally, the update usually requires all, or part of the representation to be re-rendered and the display updated (6).

A Strategy for Improving Performance

One potential approach to reducing the delays inherent in the SVG event model is to enhance the interpretive architecture described above with Just-in-Time (JIT) compilation techniques. For example, instead of relying on the traversal of a document model to render SVG elements, a JIT compiler could produce code sequences that would render the SVG directly. In such a model, the code itself would act as the representation of the SVG document. A tree model could be maintained over the code segments for interaction with the DOM, however the rendering operation would be a strictly linear process.

An initial version of this approach would consider the application of standard compiler analyses to yield optimized rendering code segments, and to isolate immutable SVG elements. Such an approach would need to achieve a balance between efficiency, code size, and the freedom to regularly adjust code segments to conform to DOM modifications. A further extension would consider possibilities for direct integration with a JIT script engine. The goal of such an approach would be to bypass the DOM and bind compiled script code directly to the compiled SVG representation. We aim to discuss the feasibility, and potential performance gains offered by a JIT compilation approach to SVG presentation.


[1] The Batik SVG Toolkit: