Figure 1: Layers of a typical OpenVG implementation.
Keywords: SVG Tiny , OpenVG , SVG player
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.
1. Introduction
2. SVG Tiny and its related API's
3. AlexVG Player B110: our SVG Tiny Player
4. Conclusion
Acknowledgements
Bibliography
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.
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.
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.
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.
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.
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].
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.
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.
XHTML rendition made possible by SchemaSoft's Document Interpreter™ technology.
