AlexVG: an OpenVG implementation

Keywords: SVG Tiny , OpenVG , commercial implementation , vector graphics library

Hwanyong Lee
Chief Engineer
Huone Inc.
Do-Gye Bldg, Dong-Cheon-dong
Daegu
702-250
Korea
hylee@hu1.com

Nakhoon Baek
Professor
School of EECS, Kyungpook National University
Sankyuk-dong
Daegu
702-701
Korea
oceancru@gmail.com

Joon Young Lee
Researcher
Huone Inc.
Do-Gye Bldg, Dong-Cheon-dong
Daegu
702-250
Korea
jylee@hu1.com

InKyun Lee
Researcher
Huone Inc.
Do-Gye Bldg, Dong-Cheon-dong
Daegu
702-250
Korea
iklee@hu1.com


Abstract


In these days, there are lots of needs for vector graphics facilities, including SVG and its applications. Especially in the web environment, SVG(scalable vector graphics) becomes one of the most important components. We also have recent emphasis on the graphics facilities for embedded systems. In the field of SVG, they provide SVG Tiny for embedded systems including mobile phones. On the other hand, Khronos group focuses on the embedded programming environment and provides various graphics standards for embedded systems. Among them, OpenVG is designed to support 2D vector graphics facilities on the embedded systems.

From the view point of SVG, OpenVG covers most of SVG Tiny rendering functions. In contrast, OpenVG does not provide other SVG Tiny features, including scene graph handling, parsing, animation, scripting and so on. These features should be independently implemented. We aim to fully implement the mobile 2D environment, in which overall features from various embedded graphics standards including SVG Tiny, OpenVG, etc. In this paper, as the most fundamental step to this goal, we presented our OpenVG engine, AlexVG, with SVG Tiny rendering support.

AlexVG, our commercial OpenVG implementation, is based on the OpenVG pipeline architecture, and implemented using the C programming language. We use fixed-point number representation for more effective calculation of real numbers, since current embedded systems are usually lacking in the floating-point acceleration hardware. We also solved some implementation issues including the followings:

robust computation: We achieved numerical stability of this graphics engine using the fixed-point number calculations.

configurable implementation: Our modular approach enables us to control the overall performance between the visual quality and its processing speed, which is relatively more important for embedded systems.

accelerated implementation: We totally re-designed some geometric algorithms to finally achieve overall accelerations.

We focused on the efficient and effective implementation for mobile and embedded devices with limited resources.

AlexVG, our OpenVG implementation was already verified through developing some SVG Tiny applications including SVG Tiny players. Now, it is also under its official conformance test. In the near future, AlexVG will become an integrated programming environment, which supports almost all graphics standards related to SVG Tiny and its applications. For more technical details, visit our official AlexVG web site, http://www.alexvg.com/.


Table of Contents


1. Introduction
2. Overview of OpenVG
3. Our AlexVG Implementation and its Related Issues
4. Conclusion
Acknowledgements
Bibliography

1. Introduction

Recently, newly designed two-dimensional graphics systems are focusing on the scalable vector graphics features, in addition to the traditional raster graphics and image handling features[1][2]. Especially in the web environment, SVG(scalable vector graphics) becomes one of the most important systems, and now we have a good deal of SVG applications. SVG is originally the language for describing two-dimensional graphics output and graphical applications in XML[2] [3]. At this time, SVG 1.1 is the latest official specification, and it is the core of the current SVG developments. Thus, especially for web browsers, it is natural to show SVG contents directly on the web pages.

Another trend in the computer graphics field is the emphasis on the graphics facilities for embedded systems. In the case of SVG, SVG Tiny is provided for the embedded systems including mobile phones and PDA's. SVG Tiny is targeted to resource-limited devices and now it is an essential part for the third generation mobile phones.

The Khronos Group[4] is a member-funded industry consortium focused on the creation of open standard, royalty-free APIs. At this time, the Khronos Group provides various graphics standards for embedded systems. Among them, OpenVG[5][6] is established to support 2D vector graphics on the embedded systems. OpenVG is a royalty-free, cross-platform API that provides a low-level hardware acceleration interface for vector graphics libraries such as Flash and SVG.

In the Java community, JSR226[7] was established for Java binding of SVG Tiny 1.1, and later, JSR287[8] for SVG Tiny 1.2. All these efforts from various organizations would be finally integrated into a single standard, through their cooperation. For example, Khronos Group and JSR271[9] and JSR287 groups cooperate with each other in their standard specifications, and the next version of OpenVG 1.1 are expected to include all the major rendering functions in JSR271 and JSR287.

In this paper, we present the implementation process and its related issues for a commercial OpenVG product, which effectively provides most of important features for the SVG Tiny and its applications. Chapter 2 presents an overview of OpenVG standard. Its implementation and related issues are followed in Chapter 3. Finally, we conclude this paper in Chapter 4.

2. Overview of OpenVG

OpenVG is an open standard for platform-independent hardware-based acceleration of 2D vector graphics systems. According to its official specification, OpenVG provides a drawing model similar to those of existing two-dimensional drawing APIs and formats, such as Adobe PostScript[10], PDF[11], Flash[12], Sun Microsystems Java2D[13], and SVG[2][14]. They also say that OpenVG is intended to support all drawing features required by a SVG Tiny 1.2 renderer.

From the viewpoint of SVG, OpenVG covers most of SVG Tiny rendering function, so it can be implemented on OpenVG. However, when examined more precisely, OpenVG lacks scene graph, parsing, animation, link and scripting features. Thus, these features should be implemented separately. In any case, the OpenVG can provide most features of SVG, and thus, we implement the OpenVG engine on embedded systems, especially for mobile phones, to finally provide SVG functionalities.

alexvgfig01.png

Figure 1: Overall structure of OpenVG

We started from analyzing the overall structure of OpenVG for its full implementation. As shown in Figure 1, OpenVG has a device controller layer, named EGL[15], just above hardware devices. The OpenVG itself consists of Engine(core), API(language binding) and Utilities. Over the OpenVG system, there may be applications based on Brew, Java, etc. Since OpenVG isolates device-dependent parts into the device controller layer, EGL, the core of OpenVG engine can be used on various platforms, even without any modifications.

An ideal implementation of OpenVG may have an overall pipeline with 8 stages, as described in the OpenVG official specification. Since the implementers are not restricted to use the ideal pipeline mechanism, they can use any variations and/or even their own internal architectures. The only restriction is to provide the same result as the specification described.

At the early design stage of our implementation, we decided to aim to a robust and efficient implementation. Thus, our AlexVG implementation is fundamentally based on the official 8-stage pipeline architecture. To accelerate the overall performance, we modified some minor details of this architecture, during the later implementation stage. However, the overall and fundamental architecture is not stained.

alexvgfig02.png

Figure 2: OpenVG rendering pipeline

The overview of the OpenVG pipeline is represented in Figure 2. As shown in the official specification[6], this figure is focusing on the various steps to draw a thick, dashed line into a scene using a radial gradient paint. The eight stages and its processing details can be summarized as follows. See the OpenVG specification[6] for more details.

From the viewpoint of developing application programs, a programmer specifies output paths or drawing parameters using the OpenVG API, as the action in the stage 1. When the drawing functions such as vgDrawPath(...) and vgDrawImage(...) are invoked later, the graphics engine converts the object and its drawing parameters into detailed bitmap information, through the stages 2 to 7. In stage 8, this new source image is finally synthesized with the current output image. Through repeating all these steps for each object, we get the final image.

3. Our AlexVG Implementation and its Related Issues

We implemented the 2D vector graphics engine, named AlexVG, based on the OpenVG pipeline architecture, using the C programming language. Our vector graphics engine performs object-based processing for the paths and objects in the stages 1 to 3, while it does fragment-based (or pixel-based) processing for each pixel of the objects, in the stages 4 to 8.

For more efficiency, we use fixed-point number representation of Q16.16 for internal calculations of real numbers. Since most CPU cores used in embedded systems are integer processors, all floating point operations must be simulated using integer arithmetic. Using fixed point arithmetic instead of floating point shows remarkable performance improvements on these small CPU's. See [16] and [17] for more details on the fixed-point processing.

During implementation of our AlexVG engine, we solved lots of implementation issues including the followings:

Through the AlexVG implementation process, we run the engine and variety of sample programs on ARM9, XScale, and XScale MMX platforms. We also ported the engine on Linux, Windows CE and Nucleus operating systems. A variation modified to use floating-point arithmetic is also available for Windows 2000/XP-based computers.

We have tested all the facilities in our pipeline architecture and features specified in the OpenVG, as shown in Figure 3. Currently, we are processing the OpenVG official conformance test, while we also officially participate in the development of OpenVG conformance test suite.

alexvgfig03.png

Figure 3: Selected demonstration images from AlexVG implementation results

Finally, our AlexVG engine shows the following features in addition to the original OpenVG features:

4. Conclusion

In this paper, we presented our OpenVG engine, AlexVG, as the fundamental part to fully implement the mobile 2D environment, where SVG Tiny can be a typical example. Some previous OpenVG implementations used a 3D graphics library such as OpenGL or OpenGL ES as its underlying layer, for rapid commercialization. In contrast, our AlexVG engine focuses on the efficient and effective implementation for mobile and embedded devices with limited resources, and thus, we implemented a fully independent engine. Our AlexVG engine is now under its official conformance test[18].

AlexVG provides considerably most features of SVG Tiny, and thus, we can easily build up SVG-based application programs. As an example, we have already implemented a commercial SVG Tiny player, AlexVG Player B110 based on the AlexVG engine[19].

Since all the standards directly-related to SVG, including OpenVG, JSR226, JSR271 and JSR287, tend to be integrated into a unified standard, AlexVG, our OpenVG implementation, will also vary along their changes. In a long term period, AlexVG will be an integrated programming environment supporting almost all graphics standards related to SVG Tiny and its applications. For more technical details and/or questions, visit our official AlexVG web site[20].

Acknowledgements

This research was supported by the Regional Innovation Industry Promotion Project which was conducted by the Ministry of Commerce, Industry and Energy(MOCIE) of the Korean Government (70000187-2006-01).

Bibliography

[1]
T. Evans, Introducing Macromedia Flash Lite 1.1, Logged In, Macromedia Developer Center, 2004.
[2]
W3C Recommendation, Scalable Vector Graphics (SVG) Tiny 1.2 Specification, 2006.
[3]
http://www.w3.org/Graphics/SVG/
[4]
http://www.khronos.org/
[5]
http://www.khronos.org/openvg/
[6]
Khronos Group, OpenVG Specification, version 1.0.1, Khronos Group, 2005.
[7]
Java Community Process, JSR226: Scalable 2D Vector Graphics API for J2ME, JCP, 2005.
[8]
Java Community Process, JSR287: Scalable 2D Vector Graphics API 2.0 for Java ME, JCP, 2006.
[9]
Java Community Process, JSR271: Mobile Information Device Profile 3, JCP, 2006.
[10]
Adobe Systems Incorporated, PostScript Language Reference Manual, 3rd Edition, Addison-Wesley, 1999.
[11]
Adobe Systems Incorporated, PDF Reference, 6th Edition: http://www.adobe.com/devnet/acrobat/pdfs/pdf_reference.pdf
[12]
Macromedia, Inc., Macromedia Flash Developer Center: http://www.adobe.com/devnet/flash
[13]
Sun Microsystems, Inc., Java 2D API Home Page: http://java.sun.com/products/java-media/2D
[14]
W3C Recommendation, Scalable Vector Graphics (SVG) Full 1.2 Specification, 2006.
[15]
Khronos Group, Native Platform Graphics Interface 1.2, Khronos Group, 2005.
[16]
ARM, Fixed Point Arithmetic on the ARM, Application Note 33, ARM, 1996.
[17]
D. Hough, Applications of the Proposed IEEE-754 Standard for Floating Point Arithmetic, IEEE Computer, Vol.14, no.3, 1981.
[18]
Khronos Group, OpenVG Conformance Test Process, OpenVG Workgroup , June 2005.
[19]
H. Lee et.al, AlexVG player: an SVG Tiny Player, SVG Open 2007, 2007.
[20]
http://www.alexvg.com/

XHTML rendition made possible by SchemaSoft's Document Interpreter™ technology.