AlexVG player: an SVG Tiny 1.1 Player

Keywords: SVG Tiny , OpenVG , SVG player

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

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

Aekyung Oh
Researcher
Huone Inc.
Do-Gye Bldg, Dong-Cheon-dong
Daegu
702-250
Korea
oak@hu1.com

Myoung Lan Jo
Graduate Student
School of EECS, Kyungpook National University
Sankyuk-dong
Daegu
702-701
Korea
sihura@hotmail.com


Abstract


SVG is one of the most important components in the web environment. They also provide SVG Tiny for vector graphics facilities on small scale embedded systems including mobile phones. On the other hand, OpenVG is a 2D vector graphics API for embedded systems, which is established by Khronos group. In this paper, we present an SVG Tiny 1.1 Player on our OpenVG implementation. Since OpenVG covers most of rendering functions in SVG Tiny standard, our implementation strategy would be an efficient and cost-effective way of implementing SVG Tiny applications especially on small-scale embedded systems.

OpenVG focuses on the efficient implementation of vector graphics applications. It aims to not only hardware acceleration features but also efficient software implementations. In near future, lots of chip vendors and solution providers will provide hardware and software OpenVG products. These OpenVG products will be available on many handheld devices and embedded systems. Thus, especially from the view point of cost-effectiveness, it would be a good choice to develop various applications on this graphics API.

When we already have an existing OpenVG implementation, it is intuitive and relatively easy to implement SVG Tiny applications, based on the existing OpenVG facilities. As an example, most of SVG Tiny rendering features can be achieved by the OpenVG rendering pipeline, whose rendering performance may be even better with smaller code size. In this case, another benefit can be the reduced size of the footprint of the SVG Tiny applications.

Since OpenVG covers most of SVG Tiny rendering functions, SVG Tiny and its applications can be implemented on the OpenVG. In contrast, OpenVG does not provide functionalities for scene graph handling, parsing, animation, link and scripting. Thus, we need to implement these additional features, which are not directly supported by OpenVG.

To show the correctness and benefits of our implementation strategy, we implemented an SVG Tiny 1.1 Player, named AlexVG Player B110, on our OpenVG implementation, AlexVG. This application program starts from SVG parsing stage. The parsed SVG element trees are traversed to prepare the OpenVG attributes for the final rendering stage. This application program uses an internal stack to manage the SVG attributes. We expect that this implementation result shows an efficient and cost-effective way of implementing SVG Tiny applications.

In contrast, OpenVG rendering pipeline can handle only one graphics context, and thus, all primitive drawings from SVG Tiny should be passed to the OpenVG pipeline one by one. It may become a bottleneck for the rendering speed. If other graphics API's or the next version of OpenVG provide multiple graphics contexts, further research is needed for organizing the SVG scenes to optimize the rendering API calls, to finally reduce the number of passes in the underlying OpenVG pipeline.


Table of Contents


1. Introduction
2. SVG Tiny and its related API's
3. AlexVG Player B110: our SVG Tiny Player
4. Conclusion
Acknowledgements
Bibliography

1. Introduction

SVG(scalable vector graphics) is now one the most important systems especially in the web environment, along with the preference of scalable vector graphics features in the two-dimensional graphics output. Although SVG was originally the graphics output description language in XML, we have lots of SVG applications at this time[1][2][3].

Additionally, OpenVG is another two-dimensional vector graphics API, which focuses on the efficient implementations on embedded systems[4][5]. This standard is established by the Khronos Group[6], a member-funded consortium focused on the creation of open standard, royalty-free API's. Among the Khronos group's various graphics standards for embedded systems, OpenVG is established to support 2D vector graphics on the embedded systems.

tplayerfig01.png

Figure 1: Layers of a typical OpenVG implementation.

Though OpenVG originally focuses on the effective way of hardware accelerations, it also aims to efficient software implementations, as shown in Figure 1. OpenVG is not a competitor with existing formats but provides a low-level hardware acceleration interface for vector graphics libraries such as Flash[7] and SVG. For its efficiency, OpenVG is based on the 8-stage pipeline architecture[4], as shown in Figure 2.

tplayerfig02.png

Figure 2: OpenVG rendering pipeline.

In near future, hardware vendors and solution providers will provide hardware and software OpenVG products. These OpenVG products will be available on many handheld devices and embedded systems. Thus, especially from the view point of cost-effectiveness, it would be a good choice to develop various applications on this graphics API.

In this paper, we present an SVG Tiny 1.1 Player implementation on our OpenVG engine. Since OpenVG covers most of rendering functions in SVG Tiny standard, our implementation strategy would be an efficient and cost-effective way of implementing SVG Tiny applications especially on small-scale embedded systems.

Chapter 2 presents a comparison between some two-dimensional vector graphics standards, including SVG, OpenVG and some JSR(Java Specification Request)'s. Based on this comparison, our strategy and its result, AlexVG player B110 is presented in Chapter 3. Finally, concluding remarks and future work are followed in Chapter 4.

2. SVG Tiny and its related API's

In addition to OpenVG, several Java Specification Requests(JSR's) are also closely related to SVG[1]. In this section, we show their comparisons, to finally recognize that there would be a cost-effective way of implementing all or some of these closely-related standards.

In the first place, JSR226[8] is the Java Binding for SVG Tiny 1.1. Recently, new JSR projects related to SVG and OpenVG are also started. JSR271[9] defines an optional package for rendering enhanced two-dimensional vector graphics and rich media contents based on selected features from SVG Mobile 1.2, with primary emphasis on MIDP(Mobile Information Device Profile).

JSR287[10] includes functions for advanced immediate-mode rendering API's, which are compatible with OpenVG. JSR271 will specify the third generation Mobile Information Device Profile (MIDP3), expanding upon the functionality in all areas as well as improving interoperability across devices. In this JSR, there will be scalable vector graphics functions. OpenVG workgroup from Khronos group starts to define a new OpenVG specification, to newly include supports for flash player and font rendering.

Table 1 shows comparisons of various JSR's and OpenVG specifications with respect to SVG Tiny. Note that some information may change since some projects are going on. Khronos group, JSR271 and JSR287 are cooperating with each other in establishing their specifications, and the next version of OpenVG 1.1 will cover all major rendering functions of JSR271 and JSR287.

Comparison of features in JSRs and OpenVG

Feature

JSR226

JSR271

JSR287

OpenVG

1.0

OpenVG

1.1

Shapes

(Rounded) Rectangle

Yes

Yes

Yes

Yes*

Yes*

Circle/Ellipse

Yes

Yes

Yes

Yes*

Yes*

Line/Polyline/Polygon

Yes

Yes

Yes

Yes

Yes

Path Operations

MoveTo/LineTo/Close

Yes

Yes

Yes

Yes

Yes

Bezier (Cubic, Quadratic)

Yes

Yes

Yes

Yes

Yes

Arc

No

?

No

Yes

Yes

G1 Smooth Bezier

Yes

No

Yes

Yes

Yes

Query: Length/Tangent

No

No

No

Yes

Yes

Query: Bounding Box

Yes

No

Yes

Yes

Yes

Screen Bounding Box

Yes

No

Yes

Yes

?

Path Transform

Affine Transform

Yes

Yes

Yes

Yes

Yes

Projective Transform

No

No

No

No

Yes

Images

Affine Transform

Yes

Yes

Yes

Yes

Yes

Projective Transform

No

No

No

Yes

Yes

Image Overlay

No

Yes

Yes

Yes

Yes

Child Image

No

No

No

Yes

Yes

Image Filter

No

No

No

Yes

Yes

Fill

Fill Color

Yes

Yes

Yes

Yes

Yes

Fill Gradient

No

No

Yes

Yes

Yes

Fill Pattern

No

No

Yes

Yes

Yes

Fill Rule

Yes

No

Yes

Yes

Yes

Stroke

Stroke Color

Yes

Yes

Yes

Yes

Yes

Stoke Gradient

No

No

Yes

Yes

Yes

Stroke Pattern

No

No

Yes

Yes

Yes

Line Cap/Join/Miter

Yes

Yes

Yes

Yes

Yes

Dashing

Yes

Yes

Yes

Yes

Yes

Non-scaling Stroke

No

Yes

No

No

Yes

Blending Modes

Src over Dst

Yes

Yes

Yes

Yes

Yes

Over & In

No

Yes

No

Yes

Yes

Mult, Scrn, Darken, Lighten

No

No

No

Yes

Yes

Clear

No

Yes

No

No

No

Text Rendering

Wrapping in bounding box

No

Yes

Yes

No

Yes

Transformation

Yes

Yes

Yes

No

Yes

Rendering

Anti-aliasing (Choice)

Yes

Yes

Yes

No

Yes

Color type/Pixel Layout

No

No

Yes

Yes

Yes

Clipping (Target Surface)

Yes

Yes

Yes

Yes

Yes

Scissoring Rect

No

No

No

Yes

Yes

Alpha Masking

No

No

Yes

Yes

Yes

* Implemented in VGU(OpenVG Utility library).

Table 1

As shown in Table 1, OpenVG covers most of SVG tiny rendering function. Therefore, SVG tiny can be implemented on OpenVG. In contrast, OpenVG does not have functions for scene graph handling, parsing, animation, link, and scripting, which may be implemented independently.

When we already have an existing OpenVG implementation, it is intuitive and relatively easy to implement SVG Tiny applications, based on the existing OpenVG facilities. As an example, most of SVG Tiny rendering features can be achieved by the OpenVG rendering pipeline, whose rendering performance may be even better with smaller code size. In this case, another benefit can be the reduced size of the footprint of the SVG Tiny applications. We can also use this strategy to support another vector graphics standard, to reduce the development cost.

Since OpenVG covers most of SVG Tiny rendering functions, SVG Tiny and its applications can be implemented on the OpenVG. In contrast, OpenVG does not provide functionalities for scene graph handling, parsing, animation, link and scripting. Thus, we need to implement these additional features, which are not directly supported by OpenVG.

3. AlexVG Player B110: our SVG Tiny Player

tplayerfig03.png

Figure 3: OpenVG rendering pipeline.

To show the correctness and benefits of our implementation strategy, we implemented an SVG Tiny 1.1 Player, named AlexVG player B110, on our OpenVG implementation, AlexVG, as shown in Figure 3. This application program starts from the SVG parsing stage. The parsed SVG element trees are traversed to be rendered with their corresponding attributes. This application program uses an internal stack to manage the SVG attributes. We expect that this implementation result shows an example for the efficient and cost-effective way of implementing SVG Tiny applications.

Traditional work flow of a SVG Tiny player can be summarized as the following steps:

From the viewpoint of SVG, the most significant lack in OpenVG is "text and font" facilities. Since Khronos Group, the establisher of OpenVG standard, has royalty-free policy, they cannot include especially the outline font system, due to intellectual property issues, at the standard specification time. Now, we have some royalty-free outline font systems, and thus, OpenVG 1.1 specification has these "text and font" facilities.

HUONE Inc.[11] announced their first SVG Tiny 1.1 Player named AlexVG player B110, which is running on their OpenVG engine implementation. During its implementation, they use the AlexVG engine, their software implemented OpenVG product[12][13].

tplayerfig04.png

Figure 4: Global view of AlexVG Player B110 internal processing

Figure 4 is the flow chart of major functions for our AlexVG player B110. As shown in the flow chart, it starts from parsing the SVG document and generates a tree structure with SVG elements. At the rendering stage, this tree is traversed in a top-down manner and processing the attributes and animation data. Shape and image-related elements need to draw their corresponding graphics results, and thus, they set graphics context parameters using vgSet(...) functions of OpenVG. The final rendering steps are performed using vgDrawPath(...) or vgDrawImage(...) functions, to draw graphics results on the screen.

Some attributes in SVG are inherited to their child elements. For example, the stroke color is assigned in the <g> element, its child element <line> is drawn with this stroke color, when the <line> element has no specific stroke color attribute. For all these inheritance processing, we need an internal attribute stack.

For the container elements such as <svg> and <g> elements, their drawing-related attributes including fill colors, stroke colors and so on are pushed on the stack. When processing their children, the unspecified attributes are fetched from the stack top, to conclusively inherit from their parent. After traversing all the children, the corresponding attributes are popped out.

When there are any animation elements in the SVG parsing tree, we calculate the animated attribute values for each rendering time, and repeatedly update the corresponding attribute values for the elements, to finally generate the animated results. When the tree traversal is completed, the target screen will be finally rendered with the OpenVG functions such as vgDrawPath()'s and vgDrawImage()'s. When the animation is still continuing, the rendering process is repeated, as shown in Figure 4. Overall process of AlexVG player B110 is now implemented and commercially available for various platforms. Figure 5 shows a few samples from the various SVG documents used for feature tests of our AlexVG player B110.

tplayerfig05.png

Figure 5: SVG documents for test and demonstration

4. Conclusion

In this paper, we presented an SVG Tiny player, named AlexVG player B110, which fully utilize the OpenVG standard as the underlying layer. Since OpenVG is originally designed to support existing two-dimensional vector graphics API's, our implementation strategy is expected to be a cost-effective way of implementing SVG applications on the existing OpenVG engine. Conclusively, when we have an OpenVG implementation, it is intuitive and relatively easy to implement an SVG Tiny player, based on the existing OpenVG facilities.

OpenVG specification, however, has much plenty of functions for rendering and also a complex rendering pipeline architecture. Thus, in the case of software implementation of OpenVG, SVG Mobile player implemented on the OpenVG may show relatively low performance in comparison with a dedicated and optimized SVG Mobile player. As you can easily imagine, OpenVG-based implementation is not an economically reasonable choice for devices only requiring SVG Mobile player, since OpenVG rendering pipeline is somewhat expensive.

Implementation of SVG applications on the OpenVG standard has another performance drawback, at this time. Current OpenVG rendering pipelines can handle only one graphics context, and thus, all drawing primitives from SVG Tiny should be passed to the OpenVG pipeline one by one. It may be a bottleneck for the rendering speed. If other graphics API's or the next version of OpenVG provide multiple graphics contexts, further research is needed for organizing the SVG scenes to optimize the rendering API calls, to finally reduce the number of passes in the underlying OpenVG pipeline.

Acknowledgements

This work was supported by the second stage of the Brain Korea 21 Project in 2007.

Bibliography

[1]
W3C Recommendation, Scalable Vector Graphics (SVG) Tiny 1.2 Specification, 2006.
[2]
W3C Recommendation, Scalable Vector Graphics (SVG) Full 1.2 Specification, 2006.
[3]
http://www.w3.org/Graphics/SVG/
[4]
Khronos Group, OpenVG Specification, version 1.0.1, Khronos Group, 2005.
[5]
http://www.khronos.org/openvg/
[6]
http://www.khronos.org/
[7]
Macromedia, Inc., Macromedia Flash Developer Center: http://www.adobe.com/devnet/flash
[8]
Java Community Process, JSR226: Scalable 2D Vector Graphics API for J2ME, JCP, 2005.
[9]
Java Community Process, JSR271: Mobile Information Device Profile 3, JCP, 2006.
[10]
Java Community Process, JSR287: Scalable 2D Vector Graphics API 2.0 for Java ME, JCP, 2006.
[11]
http://www.hu1.com/
[12]
http://www.alexvg.com/
[13]
H. Lee et.al., AlexVG: an OpenVG implementation, SVG Open 2007, 2007.

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