Creating and Implementing Mobile SVG

Bella Robinson
CSIRO Australia
Mathematical and Information Sciences Division
GPO Box 664, Canberra ACT 2601, Australia
phone: +61 2 6216 7049
fax: +61 2 6216 7111

Keywords: Mobile SVG; SVG Viewer; Pocket PC; WinCE


The Mobile SVG profiles, SVG Basic and SVG Tiny, define XML grammars for describing resolution-independent two-dimensional graphics on mobile devices, such as cellular phones and personal digital assistants. Mobile SVG enables a large number of applications, such as location based services, mapping applications, animated picture messaging and industrial control to name a few.

However, when it comes to using and implementing Mobile SVG, there are a number of difficulties. How do you efficiently implement such a large specification on such a constrained device? A typical mobile phone has a small amount of memory and a slow processor. A PDA has slightly more memory and processing power, but both have small resolution displays. Even though Mobile SVG was specifically designed to make SVG as easy as possible, a user agent still has to implement XML parsing, scripting, the DOM, image libraries and rendering. Additionally, SVG content can have a dramatic affect on rendering performance. What considerations should be taken into account when generating SVG content for mobile devices? What is the tradeoff between content volume and the geometric description of entities?

Given the advantages SVG provides to desktop machines - resolution independence, XML graphics and a small file size - are equally beneficial in the resource limited area, it is important that everyone understands how to best produce exciting graphical content for small devices.

The paper will describe some of the difficulties involved in implementing a Mobile SVG viewer, and why it is useful to keep these issues in mind when creating content for mobile devices. It will also describe the methods provided by the SVG specification to assist in the creation of SVG files that are expected to render on all profiles of SVG. This will include effective use of conditional content in the SVG file, and the ways that it can be processed on the server or on the client. There may also be cases where it is acceptable for the SVG application to trade geometric accuracy for file size.

1. Introduction

The SVG standard has come a long way over the last two years; it is showing all the vital signs of becoming widely accepted as the mainstream standard for 2D web graphic content. The desktop environment however, has the benefit of relatively fast processors with plenty of memory and high performance graphics hardware, although one can still find SVG content (usually containing animation) that will render very poorly on a high-end desktop machine. This is even more problematic on mobile devices that are highly constrained with respect to CPU power, available memory and graphics displays. The implementation of a functional SVG viewer on these devices is an exercise in matching user requirements (what do users want) with hardware capabilities (what can be delivered). The current effort in Mobile SVG Profiles is simply recognizing the fact that while the SVG 1.0 Specification may be suitable for the desktop environment, it is highly unsuitable for mobile devices.

This paper describes some of the major considerations taken into account during the implementation of a product called PocketSVG - a toolkit to render SVG content on Microsoft Windows CE (WinCE) based portable devices. Section 2 discusses the basic architecture and the significant performance issues of the various components of the architecture. Section 3 attempts to address some aspects of SVG content generation that affect performance. Section 4 provides a number of examples of SVG content that were used during the development PocketSVG.

2. Implementing an SVG Viewer

2.1 Target platform and programming language

At the time of initial implementation, the choice of platform was limited to Palm/PalmOS, Psion/EPOC or WinCE devices. This was a time (mid 2000) when Palm devices were dominant in the PDA (personal digital assistants) market, but new WinCE based devices, Pocket PCs, were just entering and showing signs that they would make a sizeable impact on Palm's dominance (which they have done). Pocket PCs from manufacturers such as Hewlett-Packard, Casio and Compaq had recently entered the market and were receiving good reviews from end users. These devices, with faster CPU's, more memory and better (colour) screens were significantly more powerful than Palm devices. Thus looking for a PDA with the fastest processor, the most memory and good graphics resulted in the WinCE based Pocket PC being chosen as the platform to implement an SVG Viewer. This decision was also affected by the fact that the development team had existing skills with the Microsoft Windows development environment (Visual Studio) making the transition to Microsoft eMbedded Visual Tools (the development environment for WinCE) relatively easy compared to the PalmOS SDK.

Choice of programming language was not really an issue. Having previously produced the Open Source CSIRO SVG Toolkit, Java was briefly considered as the programming language. The additional overhead of requiring a Java run time environment, performance issues for graphics rendering in Java and the non-existent support for Java2D on the WinCE environment made C++ the obvious choice.

2.2 Architecture

The architecture of the PocketSVG viewer is shown Figure 1. The software can be built in two different configurations: as a standalone viewer or an ActiveX control. Both of these modules (Viewing Application or the ActiveX Control in the architecture diagram) contain all of the relevant user interface functionality as well as the very high level graphics functionality where the off screen buffer containing the result of the SVG rendering process is finally transferred to the on screen display via the BitBlit() function call. These modules also control the animation redraws if the current SVG document is animated and of course the ActiveX module also contains the COM objects which the user can interact with when using the control embedded in an application such as a web browser.

The two overriding design criteria for the viewer were that of modularity and portability. That is, the software had to be flexible so that it would be easy to add or remove functionality. This in turn would provide portability when moving to environments that were more constrained in terms of memory, CPU power and graphics ability such as mobile phones or less constrained such as the desktop environment. A major factor affected by CPU power is that of animation. The software can be built as either a static or dynamic SVG viewer, with the dynamic SVG component simply extending the static SVG one. Graphics rendering is also very dependent on the graphics support provided by the operating system. Removing this interdependence also increases the portability and provides the ability to plug in 3rd party graphics libraries. On the WinCE platform the Graphics module depicted in Figure 1 can rely heavily on the native graphics (GDI) support provided by the operating system or implement many of the graphics primitives within the module itself and rely minimally on the operating system calls.

The XML Parser module is responsible for parsing the SVG and constructing an SVG DOM tree. It uses a factory class to create the required SVG elements, currently either static or dynamic. Internally we have an XML DOM implementation, which the SVG classes extend. Most of this functionality is not available via the ActiveX interface though. The Utils module contains several useful classes such as: a base64 decoder, elliptical arc and bezier path calculators, a transform list parser, a colour decoder and a true type font reader. Both the SVG and Graphics modules use this.

PocketSVG Architecture

Fig 1. PocketSVG Architecture

2.3 XML Parser

A secondary design requirement for the SVG viewer was that it be as lightweight as possible. Rather than use a full XML parser a very simple parser was implemented, which read plain text XML files and constructed a simple DOM tree consisting only of elements, attributes and text nodes. This has since been extended to cope with the use of entities - both user defined and standard character ones, CDATA sections, Unicode characters and UTF8/UTF16 encoding.

The possibility of using a 3rd party XML library was considered, however implementations at that time were also in early stages of development and more interested at compliance with the relevant DOM and SAX standards that were evolving. A fully capable XML parser such as Xerces-C++ XML Parser was simply too large to port to the WinCE environment.

2.4 Graphics libraries

While the Windows GDI graphics support in WinCE produced reasonably fast rendering, it had many limitations, such as no anti-aliasing, no transformations and no alpha-compositing. The shape transformations could be done manually, although stroke outlines were not transformed correctly. The lack of anti-aliasing and alpha-compositing however were the most significant limitations of the GDI. These were considered an essential requirement for high quality graphics, and since Pocket PC's like the Compaq iPAQ have reasonably fast processors (200MHz ARM) it seemed feasible to implement these in software.

Existing open source graphics libraries with this functionality were ported to WinCE and trialed with the SVG viewer. These were Libart and Zodius. Both of these libraries provide anti-aliasing, transformations and alpha-compositing support, however they did not provide the full capabilities required to render SVG. They were also significantly slower than the Windows GDI calls. After playing around with both libraries, modifying them to do what was needed to render SVG and chasing a number of bugs it became clear that a clean implementation from scratch of a low level graphics library was required. This also eliminated the constraints of the license conditions imposed by each library.

2.5 ActiveX Control and DOM support

When thinking about how Mobile SVG was going to be used, it became clear that a standalone viewing application wasn't going to be particularly useful. A component based approach (in the Windows environment this means ActiveX control) would enable developers to quickly and easily add SVG support to their mobile applications. A control would also have the advantage of being easily embedded in an HTML page within a browser (Internet Explorer) where JavaScript could be used to interact with it.

Creating the control should have been a fairly simple procedure, however due to the lack of documentation on developing controls for Windows CE devices it turned out to be quite a difficult and frustrating task. The documentation provided by Microsoft was either very hard to find, incomplete or non-existent.

Initially a very minimal interface was provided to the control. This allowed the user to set/get the current SVG URL, set or refresh the viewport and set the current zoom and pan modes. However it became clear that some level of interaction with the document was required, though a full SVG DOM implementation would bloat the code considerably - an additional 160 classes would need to be implemented. A minimal interface to the DOM was added, this included element creation and insertion of elements into the current document, setting and getting attribute values and removing elements. Also, to allow applications to support user interaction with elements, events such as DocumentLoaded(), Click() and ElementSelected() were added.

2.6 What SVG features to implement?

Initially the simple and most commonly used elements and features were implemented. These included all of the basic shapes and paths, with simple filling and stroking. With the emergence of the SVG Tiny and SVG Basic mobile profiles this provided some guidelines on what should be included and what could be excluded for the Pocket PC platform. Apart from a few minor features, PocketSVG now supports the Tiny profile plus several Basic features such as gradient painting and symbols.

Supporting the text elements posed significant problems due to the requirement to be able to transform and stroke text similar to any other graphic element. This involved converting each character into a path and then rendering as a path element. To achieve this glyph placement code is required, especially for tspan elements.

To implement stroking that would transform correctly, it was necessary to create a new path for the graphic element that represents the outline of the stroke. This path was then filled to create the stroke. All of the line join and line cap methods are supported.

2.7 Performance

When implementing an SVG viewer on the Pocket PC platform, performance becomes the overriding issue followed closely by memory availability. The reduced amount of processing power and memory means that any performance bottlenecks or memory leaks are more quickly apparent. Memory leaks are easily eliminated, however speeding up the performance bottlenecks has been more difficult. The following table shows some timing figures for loading the tiger example SVG file. All times quoted are in milliseconds.

Table 1. Timing Figures
Action Time (ms)
Load file from file system 41
Parse the XML creating an SVG DOM tree 1092
Render DOM tree to off screen buffer 7890
BitBlit() the off screen buffer to screen 944
Render DOM tree to off screen buffer to show zoom 1601
BitBlit() the off screen buffer to screen 95

The most expensive part of the rendering pipeline is the initial rendering of the DOM tree to the off screen buffer. This is because the graphics objects such as paint objects and paths need to be calculated and created in this stage. These objects are then cached for subsequent redraws, which is why the zoom redraw took only a fraction of the time. Code profiling indicates that floating point operations and memory allocation and de-allocation cause the most significant bottlenecks on Pocket PC devices.

Floating point operations are not implemented by the hardware in the Pocket PC's we have tested so far (HP Jornada 548, Cassiopeia EM-500 and the Compaq iPAQ) and so they are very slow. Initially double precision was used for all coordinates and calculations. Simply changing this to be single precision floats halved the rendering time. Where possible the number of floating point function calls such as sqrt(), cos() and sin() have been minimized to improve performance. This is particularly noticeable in the radial gradient painting code where the colour for each pixel is calculated and requires extensive use of sqrt(), cos(), sin() and acos() function calls. Using lookup tables for these functions achieves a speedup of approximately 4 times. This was measured using a very simple SVG file containing a single circle, radius 100, filled with a two colour off center radial gradient. While the lookup table functions aren't as accurate as the actual functions, they are good enough for gradient painting. Using lookup tables in other parts of the code however (such as calculating the stroke outline of a curved path), introduces noticeable accuracy errors.

Memory management in the Windows CE operating system consumes significant amounts of CPU time. When rendering large documents, the time taken seems to be proportionally far longer than when rendering a smaller document. Often when viewing a large document, to load a new document it is faster to close the application and restart, than to simply open another file. Deleting one document from memory and loading another seems to be an expensive operation when dealing with large documents.

The following graphs show the time taken to load and reload files of varying size. Each file contained 100, 200, 300 or 400 path elements each consisting of two quadratic bezier curves that were both filled and stroked. The viewer was restarted for each different file. It is interesting to note the results using Pocket PC 2000 and Pocket PC 2002 are significantly different.

Reload Times using Pocket PC 2000

Fig 2. Reload Times using Pocket PC 2000

Reload Times using Pocket PC 2002

Fig 3. Reload Times using Pocket PC 2002

The initial load time for the larger files is much less that the reload time. This is more prominent in 2002. The times also appear to vary more in 2002, which would imply that its memory management is quite different to 2000. In 2000 there appears to be some sort of threshold number of allocations where up until the threshold point is reached it performs quite well but then degrades significantly.

To improve performance several methods have been investigated. These have included caching and reusing as many objects as possible, and allocating large numbers of objects at once. While these have had some success, after continual use the performance still manages to degrade. We suspect that in time memory becomes fragmented resulting in a rapid increase of page faults. Our testing devices have 32Mb total memory, of which about half is allocated to file system storage and another 4Mb is used for the OS, which leaves about 12Mb for the viewer application run in. In support of the fragmentation theory, the program was run where objects were not deleted at all. This allowed the viewer to render files very quickly, (and of course run out of memory) and is supporting evidence that the Windows CE memory management could do with improvement. Possibly implementing our own custom memory manager would overcome these problems.

3. Creating Mobile SVG content

When creating SVG content that will be displayed on a mobile device it is important to keep in mind the capabilities of the device. This section outlines some methods that can be used to ensure that SVG content will be displayed correctly and minimize the rendering time.

3.1 The requiredFeatures attribute

It is possible to create SVG content that will display differently depending on the capabilities of the viewer. Using the requiredFeatures attribute and the switch element allows the content creator to specify a simpler graphic to be displayed when being rendered on a mobile device. For example:

    <circle requiredFeatures="" 
        cx="50" cy="50" r="40" fill="red" filter="url(#blur)"/>
    <circle cx="50" cy="50" r="40" fill="pink"/>

In this example, a filter effect will be applied to the circle when it is rendered in a viewer that has BasicFilter capabilities, otherwise the circle will be filled pink. Each child of the switch element is evaluated until one is found that can be rendered by the viewer. All subsequent children are ignored.

The requiredFeatures attribute can be used anywhere, not just inside a switch element. When it appears on an element not inside a switch, the element is only rendered if the viewer has the required capability.

3.2 Using a server to generate Mobile SVG content

It should be possible for a server side SVG application to detect whether a mobile device is requesting data. If it is, then to reduce both the delivery time across a wireless network and the time taken to render the graphics, the generated SVG data should be customized for a mobile device. This may involve stripping out some unnecessary elements and simplifying the content. In the development of the SVG 1.0 specification, considerable effort has been made to make SVG file sizes as small as possible. It also mentions that gzip compression of data passed between server and client can result in significant file size reduction. The overhead of compression at the server, followed by corresponding decompression by the PDA client is still very small when compared to the delivery time saved.

The ASP code below shows an example of how to detect whether the request is from a WinCE device or not.

var userAgent = new String(Request.ServerVariables("HTTP_USER_AGENT"));
if (userAgent.indexOf("WinCE") >= 0) {
    // mobile WinCE device
} else {
    // assume standard browser


3.3 Specify width and height of 100% with a viewBox

To allow content to be viewable on a range of devices it is a good idea to specify the width and height of the root svg element to be 100% and use a viewBox attribute to define the coordinate system for the document. This means that when the SVG is initially displayed it will be resized to fit the viewport available on the device.

3.4 Some tips to reduce rendering time

Rendering time can be reduced quite dramatically if certain features are avoided or used sparingly. Each different viewer will have its own inefficiencies, so it may be worth experimenting with the ones you are planning to use. Of course these suggestions are mostly relevant to the PocketSVG viewer, however they may serve as useful guidelines for areas of investigation when using other viewers.

All timing figures quoted in this section have been gathered using a slightly modified version 1.0.4 of PocketSVG, running on a Compaq iPAQ 3630 with 32Mb of memory and the 2002 Windows CE operating system. All time values quoted are in milliseconds and indicate the time taken to first render the SVG. Parsing time is not included. Subsequent redraws are much faster since a lot of the data is cached.

4. Some Mobile SVG Examples

4.1 The CSIRO Home Network

The CSIRO Home Network is an example of using the PocketSVG ActiveX control in a real time data acquisition and control application. In the application the Pocket PC is used as a remote control to various appliances around the home. When the user interacts with the SVG by "turning a knob" or "flicking a switch", a message is sent over the wireless network to the home server, which modifies the state of the appliance. When initially displayed the server is also queried as to the current state of the appliance. For our demonstration, the state of the appliance was simulated on a desktop computer in SVG.

A significant problem of the demonstration is slow response time. That is, the application was quite slow at reflecting the change in state due to the user's tap of the pen on a switch or dial. One reason for this is that for each pen tap, every element needs to be tested to see if the point tapped is within the element's boundary. If so, then an event is generated for the top most graphic element and all of its ancestors. The application then needs to filter all of the incoming events to see if it needs to update the SVG graphics. Thus, the richer the user interface and the more complex the graphic content, the slower the response time. The COM interface between the application and the ActiveX control also appears to be quite slow. While this needs to be more thoroughly investigated, it brings into question the suitability of SVG for real time applications.

Select Room

Select room to control

Select appliance

Select appliance

Adjust lighting

Adjust lighting

Adjust heating

Adjust heating

Adjust air conditioner

Adjust air conditioner

Adjust stereo

Adjust stereo

4.2 Maps

Displaying maps using SVG is an ideal application for mobile devices, given that users with such devices are often in the field and need to know where they are, or where they are going. Maps however, tend to contain large quantities of graphic data and therefore are often unsuitable to render on small devices. The maps shown below were easily converted from existing mapping databases, but resulted in too much data for a single SVG file. To make the maps useable on a portable device required the extraction of small sub-regions. Rather than producing (small) static SVG maps, SVG based mapping applications are an obvious candidate for streaming content, whereby the user only downloads the map data for a given region of interest. When the region moves (pans/zooms) new content can be acquired and added to the existing view.



Propery Map

Property Map

4.3 Schematics

Like maps, schematics also tend to contain large amounts of detailed data, which can be a problem for mobile devices. By following some of the tips outlined in Section 3.4, such as joining paths with the same rendering attributes and avoiding round line caps and joins it should be possible to display quite complex SVG schematics on a mobile device.

Building Drawings

Building Drawings



4.4 Graphs

SVG graphs are particularly well suited to the mobile environment. They generally don't contain complex graphics and the ability to zoom into a particular area for more detail is very useful. Interactivity can also be easily added. For example, when the user clicks on a data point, a popup box can be displayed containing additional information.

Bar Graph

Bar Graph

Pie Chart

Pie Char





Line Graphs

Line Graphs

4.5 Graphic Art

If kept quite simple, SVG can be used to display graphic art on a mobile device. Features such as gradient painting, alpha-compositing, animation and transformations can be used to display quite a range of visual effects. However, complex graphic art typically found in desktop publishing application is only good if it exploits the advanced features supported by SVG, this in turn pushes the limits of what is capable on a PDA device. Perhaps desktop publishing applications should stay on the desktop for now.








The PocketSVG software is continually evolving and it is important that as new features are added, their impact on performance and memory requirements is carefully monitored. As requirements are different for different application domains the need for modularity is essential to keep within the constraints of the hardware devices.

The key to successful SVG applications on these devices is to ensure the requirements of the application stay within the boundaries of the device capabilities. Going beyond this boundary results in an application that runs so slow it quickly becomes unusable.


The PocketSVG web site:

SVG 1.0 Specification, W3C Recommendation 04 September 2001:

SVG 1.1 Specification, W3C Candidate Recommendation 30 April 2002:

Mobile SVG Profiles: SVG Tiny and SVG Basic, W3C Candidate Recommendation 30 April 2002:

Pocket PC information, Microsoft:

Microsoft eMbedded Visual Tools product information:

Valid XHTML 1.1!