A JAVA based SVG Viewer for the Pocket PC

Jorge Gustavo Rocha
(PhD student)
Departamento de Informática
Universidade do Minho
Portugal
jgr@di.uminho.pt

 

Introduction

The problem

When we start to think about what kind of new location based services could be realized, we can be as creative as our imagination allows. Unfortunately, when designing the solution, we need to develop it from scratch, because there are few supporting modules available. There is missing modules like viewers, interfaces to positioning systems, image acquisition and processing, information (and maps) discovery, and so on.

This limited number of powerful software platforms to support location based services limits the actual services provided, mostly because developers are spending too much time writing base modules, and less developing really new ideas. Of course, this is a consequence of the number of new sophisticated devices introduced on the market, with new processors and operating systems, but with limited software already developed taking advantage of the new technology.

The solution

To address this problem, we decided to develop a generic graphic viewer, to use as a base module for LBS on different mobile platforms. We decided, from the beginning, to use an open XML based vectorial format. SVG was chosen. There major advantages related to the use of SVG: platform and vendor independence, easy to parse (because it is written in XML), easy to integrate with scripting languages, like JavaScript, providing dynamic and interactive graphics and it is easy to generate from existing CAD/GIS tools.

Also, we had to choose an implementation language widely available and portable. We choose JAVA, because we thought it would be available on every device. The problem is the differences between virtual machines; in particular, virtual machines for PDAs are limited, in particular, regarding graphics manipulation.

Now, the main core of the viewer is running, and we decided to release it under the Open Source initiative, using SourceForge supporting tools for collaborative work (to be announced at the SVG 2003 Conference). We believe in the open software concept; the viewer will evolve when others programmers can read and modify the source code. We hope that other people will love and improve it, introducing features that we didn't think about.

Having this viewer available, programmers can build, more quickly, new things on top of it.

Related work

There are other similar projects. A good starting point about other viewers is SVG Implementations.

One of the best JAVA SVG Viewer available is Batik, developed under the Apache XML project. Unfortunately, it can't run on small devices, because PDA's virtual machines are limited JAVA machines, not supporting the JAVA 2 API. Batik takes full advantage and uses extensively the JAVA 2 API.

For mobile devices, few viewers are available to render SVG, and most important, to use as a module (providing mechanisms to build on top of them). At this time, the Tiny SVG Viewer is now an SVG player and SDK, which can be integrated in mobile solutions. Also, the CSIRO SVG Toolkit is now a platform to develop mobile applications using SVG graphics. Both products are commercial available, and both are important references in this field.

To concept, to prototype, and to evaluate new ideas related to mobile computing (namely new LBS), we think that and alternative open source SVG viewer should be available.

Small devices limitations

When programming for small devices, with limited resources, some keys points are worth to mention.

First of all, there are limitations related to the use of JAVA. The tested virtual machines did not support the JAVA 2 API, and also have limited support do interact with the operating system and to access the hardware, like communication ports.

Secondly, the PDA is has limited screen resolution (240x320 on the Pocket PC). On this reduced screen size, the user rapidly get lost when navigating with a road map. The zoom operations are heavily used, to switch between larger and small scales constantly.

Also, the processor power is limited. After a huge effort to accelerate our viewer, it still takes about 8 seconds to load the full map of a medium sized city (one SVG file with 1 Mb). So, special techniques should be used to improve performance and enhance the user experience.

The input device poses no problem; from the developer's point of view, it behaves like any mouse pointer, with no special treatment.

The SVG Viewer

The viewer functionality, from the users' point of view, consist of:

SVG Support

We started before a profile for mobile devices was available. We would like to support as many features we could, from the SVG 1.1 specification. Only animations, CSS and Javascript support were left out of the initial development.

During the implementation, some other features were left behind:

Some of these features are hard to find in generated specifications. In fact, generated SVG files tend to use a small number of tags and graphical constructions. This allow us to render a large number of SVG files, while developing support for the rest of the specification.

To test and validate the developed viewer, the W3C SVG Test Suite was used.

Implementation

As we said, our viewer is written in JAVA, using the 1.1.8 API. There are three major components of the viewer: the user interface, the parser and object creation and the graphics rendering.

The parsing and object creation

The parser used (the only component not developed by us) is the crimson version 1.1.3. This is a light weigh parser (the lighter we know about).
During the parsing process, the graphical elements are extracted, and a internal list of all objects is created. Every graphical object has a corresponding JAVA class; during the parsing, for each graphical object, a new JAVA object is created. The created object captures all the characteristics of the object.

The user interface

The user interface component manages all aspects related to the user interaction: dialogs, menus, etc. This component processes all user events.

To open files, this component both supports browsing the local file system (a very slow operation within JAVA) and specifying a URL. This option improved the functionality a lot, because the user can open any remote SVG file, if the Pocket PC is connected to the Internet (over a GPRS connection, for example).

The graphics rendering

This component takes the list of created objects, and renders those relevant for the current view. This is done, basically, walking through the list of objects, rendering each one. How each object is rendered, depends on a global 3x3 matrix.

This matrix is manipulated by a new class affineTransform, because it was not available in JAVA 1.1.8.

Text rendering is very hard. There is no primitive to rotate the text, for example. To correctly handle strings, we must create a raster image with the computed size of the text. Then, the string is rendered in over this image. The image is then manipulated (rotated and filtered to make non-used pixels invisible) and finally overlapped in the larger image.

Optimization

After assembling the viewer, the performance was a disaster. We started to optimize it, in successive efforts, trying to improve performance and minimizing memory usage.

A profiling tool, JProfiler, was valuable to analyze memory usage. To accomplished this, for example, some JAVA standard classes were replaced by news ones requiring less memory. As a result, our viewer uses less memory than any other JAVA viewer tested.

To improve performance, two major techniques were used:

Future work

For us, is very reimbursing to see the SVG viewer running on the PDA. Several limitations do exists, regarding SVG support, as mentioned.
We hope that other developers find the viewer useful and join us improving the viewer, under the open source spirit.

Some considerations must be stated regarding to the use of JAVA. JAVA is not yet fully supported in the Pocket PC. Also, because there are different processors for these devices, the virtual machines do not run on every Pocket PC (In fact, three different virtual machines runs on the COMPAQ iPAQ 3850; none of them runs on the Fujitsu-Siemens Loox).
Another limitation of JAVA virtual machines is the absence of mechanisms to access certain operating system resources (like hiding the start menu and status bar), to communicate with other applications for the Pocket PC (SQL Server CE, for example) and cannot talk directly with communication ports (important to implement LBS that interfaces with a positioning device, for example).

Acknowledgments

We would like to thanks two graduate students, Nuno Faria and Noé Rocha, and PT Inovação, for supporting both during the development of the first version. Paulo Brito work hard on the viewer optimization.

We also welcome and appreciate comments from the referees of the SVG Open 2003.