Accelerating SVG Tiny with Multimedia Processors

Hwanyong Lee

Huone, Inc., Daegu, Korea. Also with School of Computer Science and Engineering, Kyungpook National University, Daegu, Korea.

Nakhoon Baek

School of Computer Science and Engineering, Kyungpook National University, Daegu, Korea. Also with Mobile Graphics Inc., Daegu, Korea. (Corresponding author:

Inkyun Lee

Huone, Inc., Daegu, Korea.

Jiyoung Yoon

Huone, Inc., Daegu, Korea.

Olivier Pothier

ST-Ericsson, Paris, France.

Denis Vallin

ST-Ericsson, Le Mans, France.

Thierry Vaulay

ST-Ericsson, Le Mans, France.

Jean-Christophe Trotin

ST-Ericsson, Le Mans, France.


Hardware acceleration of the SVG mobile player is required for larger screens and better user experiences. Currently, a feasible way of this acceleration would be realized on the OpenGL, OpenGL ES or OpenVG hardware, while these high-end hardware chips are so expensive and need much higher power consumption. In this paper, we suggest another cost-effective way of accelerating SVG mobile players, based on the wide-spread and inexpensive multimedia hardware of mobile devices. We first accelerated OpenVG with the fundamental features of multimedia hardware including bit-block transfer, image processing and blending operations, and then modified the SVG mobile player to use these accelerated OpenVG features. Our final implementation shows remarkable performance enhancement for displaying vector contents and impressive enhancements for displaying bitmap contents. Reducing a great amount of CPU work load is another important advantage of our implementation, and now CPU can be actively used for other tasks. Conclusively, our implementation delivers much better performance and reduced CPU work load to the SVG mobile players, without any additional hardware to the mobile phone devices.

Table of Contents

1. Introduction
2. Design and Implementation
2.1 Design issues
2.2 Implementation issues
3. Implementation Results
4. Conclusion

1. Introduction

Scalable Vector Graphics features exhibit many advantages including scalability in terms of display size, small file size, lossless compression capability, no compression artifacts, etc. Currently, the need for SVG[1] is high and increasing, especially on handheld devices and multimedia services where appealing user interfaces and standardized services should be supported. For an example, standards of OMA(Open Mobile Alliance) - WAP(Wireless Application Protocol), DCD(Dynamic Content Distribution) and MMS(Multimedia Message Service) require SVG Tiny[2]. In Java Standardization, JSR226 (SVGT 1.1 Java Binding)[3], JSR 287 (SVGT 1.2 Java Binding)[4], and JSR271 (MIDP3)[5] require SVG Tiny and several world-wide telecom carriers set them as basic requirement for mobile terminals. In ISO/IEC JTC1 SC29 MPEG standard, MPEG4 part 20: LASeR(Lightweight Application Scene Representation) standard[6] defines rich media services for mobile environment using SVG Tiny.

Hardware accelerated SVG players are required to support big screens with higher resolutions, to implement vivid user interfaces and rich media services. Currently available hardware accelerations for SVG players are based on the OpenVG or OpenGL (or OpenGL ES) hardware [7] [8]. OpenVG[9]. from Khronos Group is one of the most suitable API's for accelerating SVG on the handheld devices, since SVG mobile player is one of the major target applications of OpenVG.

OpenVG is a royalty-free, cross-platform API that provides a low-level hardware acceleration interface for various vector graphics libraries and applications. OpenVG primarily targets handheld devices that require portable acceleration of high-quality vector graphics for user interfaces and texts on small screen devices. Nowadays, there are a few fully-dedicated hardware solutions as well as full software implementations[8] and implementations of OpenVG on OpenGL ES hardware. OpenVG or OpenGL ES semiconductor chips are expensive for ordinary consumer markets while software implementations show relatively low performance.

In this paper, we present a way of accelerating our SVGTiny implementation on OpenVG, named AlexVG B-player[8]. We modified our OpenVG software implementation to be accelerated with the existing multimedia processing hardware which is widely adopted for image and/or video processing on a variety of handheld devices and multi-media terminals. Our major goal is to enable SVG to provide reasonably high performance graphical user experiences with lower CPU utilization without additional hardware or re-design of hardware, allowing other applications to run in parallel in CPU, providing more vivid rendering results. At least to our knowledge, this paper is the first literature communication dealing with hardware acceleration of SVGTiny applications and its underlying OpenVG using hardware which is made for other purposes.

A theoretical implementation of OpenVG implies an overall pipeline with 8 stages, as described in the OpenVG official specification[9] and also shown in Fig. 1. OpenVG features suitable for acceleration by the multimedia processor are indicated with the reddish backgrounds in Fig. 1 and can be classified as follows:

  • Double Buffering: Though double buffering is not a feature of OpenVG but feature of EGL standard. When the display controller provides double buffering capability, the OpenVG pipeline can be highly accelerated. Additional accelerations can be accomplished when partial updates are also available.

  • Blending: At its stage 8, the OpenVG pipeline provides blending and anti-aliasing features. The blending features include general Porter-Duff blending[10] and additional ones like "darken", "lighten" and "additive" operations. These blending features can be accelerated by some multimedia processors. However SVGTiny 1.2 only requires Src-Over blending, therefore if the device supports Src-Over blending, it is enough to implement SVGTiny. If there is functional overhead to support other blending mode of OpenVG (e.g. darken, lighten), we can eliminate it from OpenVG pipeline.

  • Image Copy: If the underlying image buffer provides accelerated block copy or bit-block transfer operations, we can dramatically accelerate OpenVG image handling functions including vgClear(…), vgDrawImage(…), vgCopyImage(…), and vgPaintPattern(…). With these OpenVG features, we can accelerate drawing image elements and animated images.

  • Masking and Scissoring: For some multimedia processors supporting alpha masking images, we can improve most of the pixel-level masking, scissoring and blending operations. SVGTiny does not require Mask and Scissoring feature directly but using these features, we can implement more efficient animation rendering.

  • Color Conversion and Color Transformation: Some recent multimedia processors can transform sRGB color values to its corresponding lRGB values and vice versa. We can also accelerate vgLookup(…) function using RGBA lookup table features. SVG Tiny 1.2 specification allows a SVG player implementation with assumption of colors are sRGB color. But in case of input data or video is not sRGB color, we need to translate.

  • Image Transformation: Most multimedia processors support accelerated 3×3 or 3×2 matrix multiplications, which can be directly used for the OpenVG image transformation. SVGTiny requires only 3×2 affine transform. If acceleration device supports 3×3 perspective transform, we can use the extended features of SVGTiny.

  • General Arithmetic Calculations: Most arithmetic operations and matrix operations on the 32-bit fixed number representations can be accelerated using multimedia processing chips and even their vector processing features.

After carefully analyzing the above features of the target acceleration device, we isolated the corresponding code areas from our software implementation[8] We finally re-constructed the original software implementation into several modules, each of which can be compiled to use the exiting full software implementation or the new multimedia processor accelerated implementation. Some features required for SVGTiny but not supported in OpenVG are added to OpenVG implementation. Final implementation provides the most suitable configurability depending on the available features of the underlying hardware chips.

In implementation stage, we encountered the following problems:

  • Non-Scaling Stokes: SVGTiny 1.2 has the non-scaling stroke of "vector-effect" while OpenVG 1.1 specification does not support non-scaling stroke. So, fixed pipeline OpenVG implementation has limitations to implement non-scaling strokes. If the user-specified transformation is not uniform to the horizontal and vertical directions, it cannot be implemented on fixed pipeline OpenVG devices. However, since our implementation only uses bitmap features on the hardware, we can modify the order of the OpenVG pipeline processing. We implement the non-scaling stroke by swapping the execution order of OpenVG pipeline stages 2 and 3.

  • Batch processing device: Some bitmap acceleration hardware support only batch drawing of bitmap images, but OpenVG and SVG elements must be drawn with respect to the order of appearing. To solve this problem, we implemented a delayed rendering scheme for these elements. At the rendering time, we put the depth information only and decide the order of rendering those elements, for the final batch rendering.

  • Coordinate system difference: The origin of the coordinate systems for SVG and OpenVG are located at the upper left corner and lower left corner, respectively. So before the rendering, we need an additional transformation for changing the coordinate systems. Even in the case of image coordinates, the same additional transformations are also needed.

  • Element Alpha values: SVG has the element alpha value feature to render elements with transparency. However, OpenVG does not support it directly. Therefore we emulated it with color transform function of OpenVG 1.1.

Our final implementation is tested on serveral existing multimedia processors, including baseband communication chips with bitmap processors, image processing chips for cameras of mobile devices and DSP vector processors targeted for multimedia Codec processing. We tested our implementation with serveral SVGTiny animation files and some image-oriented user interface demonstrations. Rendering results are shown in Fig. 2. We also used a set of SVG Tiny files shown in Fig. 3 to measure their performances. And we tested SVGTiny 1.2 conformance test, all result passed except some tests related to text rendering which is not implemented yet.

We selected STEricsson's multimedia acceleration hardware [11] [12] and its 2D graphic API for the sample implementation and its benchmark tests. This multimedia processing system provides most of the acceleration features listed in Section 2, except several image blending features.

Table 1 shows the graphical performances for the SVG Tiny test files. User experience appears unsatisfactory when the refresh rate is less than 15 frames per second. Due to the larger screen sizes of nowaday mobile phones, our original software implementation could barely achieve this frame rate. Our multimedia processor accelerated implementation shows dramatic performance improvement.

In Table 1, we first show the frame rates for the fully accelerated case, and then another result for slow-down version for approximately 15 frames per second version. Note that the 100% CPU utilization for the full software implementation was lowered to about 40% to 50%, which enhances the real-time multi-processing capabilities.

[8] H. Lee. N. Baek. AlexVG: an OpenVG Implementation with SVG-Tiny Support. Computer Standards & Interfaces, 31(4):661-668, 2009.

[9] D. Rice. R. J. Simpson. OpenVG Specification, Version 1.1. Khronos Group, 2008.

[10] T. Porter. T. Duff. Compositing digital images. SIGGRAPH Computer Graphics, 18(3):253-259, 1984.

[11] STEricsson. .

[12] STEricsson. .