Creating and Implementing Mobile SVG

Ms 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

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, industrial control to name a few.

However, when it comes to implementing Mobile SVG, performance requirements become the driving requirement. How do you efficiently implement such a large specification on such constrained devices? 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 low-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.

Our experience has shown that the while XML parsing is relatively fast, the DOM consumes large amounts of memory. In the rendering pipeline, traversing the DOM to render to an in memory image is very CPU intensive and requires a large amount of memory management. This is one area where significant speed improvements can be gained. Floating point operations are also very slow on mobile devices, so some clever algorithms that minimize the number of these should also improve performance.

SVG content can have a dramatic affect on rendering performance. What considerations should be taken into account when generating SVG content for mobile devices? As a very general rule, the fewer the number of graphics objects the faster the rendering speed. Of course fancy painting such as filter effects and gradient filling will slow things down. An example of how to reduce the number of graphic objects drawn is to join simple paths that have the same rendering attributes. Quite a few conversions from CAD formats have each line segment represented as an individual path element. Another way to speed things up a little is to not stroke things unless you really want to. For example there is not much point in stroking something in black if it is filled in black as well. Stroking is a lot more time consuming than simple filling since the outline of the stroke needs to be calculated before it can be filled. It is also a good idea to keep the file sizes fairly small and use hyperlinks to move between connecting graphics. For example, an SVG Viewer on a PDA will really struggle to load a large map. Consider dividing it up into smaller sections and using navigation arrows to go between the small maps.

The presentation 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.

Given that the advantages that 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.