- Email: [email protected]
AlexVG: An OpenVG implementation with SVG-Tiny support
Computer Standards & Interfaces 31 (2009) 661–668
Contents lists available at ScienceDirect
Computer Standards & Interfaces j o u r n a l h o m e p a g e : w w w. e l s e v i e r. c o m / l o c a t e / c s i
AlexVG: An OpenVG implementation with SVG-Tiny support Hwanyong Lee a, Nakhoon Baek b,⁎ a b
Huone Inc., Mobile Techno Bldg 6th Floor, Bok-Hyun-dong, Daegu 702-020, Republic of Korea School of EECS, Kyungpook National University, Daegu 702-701, Republic of Korea
a r t i c l e
i n f o
Article history: Received 21 August 2007 Received in revised form 24 May 2008 Accepted 28 June 2008 Available online 11 July 2008 Keywords: OpenVG SVG-Tiny Vector graphics library Commercial implementation
a b s t r a c t Embedded systems and web browsers have started to provide two-dimensional vector graphics features, to finally support scalability of graphics outputs, while traditional graphics systems have focused on the raster and bitmap operations. Nowadays, SVG and Flash are actively used and OpenVG from Khronos group plays the role of a de facto low-level API standard to support them. In this paper, we represent the design and implementation process and the final results of the first commercial OpenVG implementation, AlexVG. From its design stage, our implementation aims at the cooperation with SVG-Tiny, another de facto standard for embedded systems. Currently, our overall system provides not only the OpenVG core features but also a variety of OpenVG application programs and SVG-Tiny media file playing capabilities. For the conformance with the standard specifications, our system completely passed the whole OpenVG conformance test suites and the graphics output portions of the SVG-Tiny conformance test suites. From the performance point of view, we focused on the efficiency and effectiveness especially on the mobile phones and embedded devices with limited resources. As the result, it showed impressive benchmarks on the small-scale CPUs such as ARMs, even without neither any other libraries nor acceleration hardware. We had started commercial services of our AlexVG products since September 2005, and successfully entered the retail market with a good deal of mobile phones up to the present time. © 2008 Elsevier B.V. All rights reserved.
1. Introduction Recently, two-dimensional graphics systems are focusing on the scalable vector graphics features, in addition to the traditional raster graphics and image handling features [7,39]. Vector graphics outputs may preserve the final image quality without degradations such as jaggy effects due to image scaling. Thus, it has the capability of providing the same image quality regardless of display device sizes or resolutions. This feature is much valuable for downsizing usual graphics outputs onto small-size embedded systems. Currently, Macromedia Flash [22] and SVG (scalable vector graphics) [36] are widely used as the vector graphics solutions for the desktop PCs. Especially for the web environment, SVG becomes one of the most important features, and now we have lots of SVG applications. SVG is originally a language to describe two-dimensional graphics outputs and graphical applications in XML [38,39]. For web browsers, thus, it is natural to show SVG contents directly on the web pages as they did in these days. In most web browsers including FireFox [24], Safari [4] and Opera [26], SVG viewers are naturally embedded [25,27]. In contrast, Internet Explorer requires a plug-in to view SVG contents. Currently, the Adobe SVG plug-in [3] is one of the most well-known ones.
⁎ Corresponding author. E-mail addresses: [email protected] (H. Lee), [email protected] (N. Baek). 0920-5489/$ – see front matter © 2008 Elsevier B.V. All rights reserved. doi:10.1016/j.csi.2008.06.010
Another trend in the commercial computer graphics area is the emphasis on embedded systems. Getting more powerful hardware platforms, mobile systems are equipped with more advanced graphics applications including GUI (graphics user interface) managers, multimedia messaging services, GPS navigations, multimedia file players, etc. Traditional graphics systems based on the bitmap and raster operations are hard to support these new kinds of applications. Vector graphics features are needed to overcome these limitations, and now Flash-Lite [7] and SVG-Tiny [39] are introduced as their optimized versions for the small-scale embedded systems. SVG-Tiny originally targets resource-limited devices and nowadays it is an essential part for the third generation mobile phones. In contrast to this downsizing strategy starting from existing PCscale solutions, OpenVG was initiated as a native graphics standard for embedded systems. Khronos Group [15] is a member-funded industry consortium focused on the creation of open standard, royalty-free APIs. At this time, Khronos Group provides various graphics standards for embedded systems. Among them, OpenVG [16,19] is established to support two-dimensional vector graphics output on the embedded systems. OpenVG is a royalty-free, cross-platform API that provides low-level interfaces for vector graphics libraries such as Flash and SVG. In this paper, we present a commercial OpenVG implementation, AlexVG. Our AlexVG system was officially released in September 2005, as the first commercial OpenVG implementation [10]. The AlexVG system has successfully entered the commercial market
662
H. Lee, N. Baek / Computer Standards & Interfaces 31 (2009) 661–668
through being adopted for mobile phones by Samsung Electronics since 2006. We also achieved its cost-effectiveness through simultaneously supporting both of OpenVG and SVG-Tiny standards. Since the official release of OpenVG 1.0 specification in August 2005, there have been several OpenVG implementations [11,23,28,30]. However, almost all of them are based on other graphics libraries including OpenGL [31], OpenGL ES [20] and Qt [35]. Thus, they are hard to achieve software independence, and may not be free from royalty problems, which may be serious restrictions on their commercial uses. In contrast, our implementation works as a full software implementation, which directly accesses the hardware buffers, to be cost-effectively adopted by most hardware platforms without neither any major modifications nor special hardware supports. From the cost-effective point of view, it is more natural to support similar or mutually dependent graphics standards at the same time. Since one of the authors already has the experience of simultaneously implementing two international graphics standards [6], we aimed to simultaneously implement both of OpenVG and SVG-Tiny features. This strategy enables us to provide both features with less than 120 KB code space for ARM CPUs. So, we can deliver the various vector graphics outputs even on mid-tier mobile phones. The next section of this paper presents an overview of OpenVG and its related standards. Details of design and implementation issues on our AlexVG system are followed in Section 3. Implementation results and performance analysis are presented in Section 4. Finally, we conclude this paper in Section 5. 2. Background and previous works This section provides specific guidance for OpenVG and its related standard specifications including SVG, SVG-Tiny, JSRs etc. Additionally, other OpenVG implementations and their comparisons to our AlexVG implementation are presented. 2.1. OpenVG and its implementations OpenVG is an open standard for the platform-independent hardware-based acceleration of two-dimensional vector graphics systems. According to its official specification, OpenVG provides a drawing model similar to those of existing two-dimensional drawing API's and formats, such as PostScript [1], PDF [2], Flash [22], Java2D [32] and SVG [38,39]. As a kind of implementation guidelines to OpenVG developers, Khronos group provides the OpenVG conformance test suites [18]. This conformance test suites are a good indication to show how much an OpenVG implementation satisfies the official OpenVG specification. A proper implementation should show completely 100% pass rate on the conformance test suites. As the developers of the first commercial OpenVG implementation, we also officially participate in the development of these OpenVG conformance test suites. OpenVG is originally intended to support all drawing features required by the SVG-Tiny 1.2 renderer [16,19]. From the viewpoint of SVG, OpenVG covers most of SVG-Tiny rendering functions, and thus, SVG-Tiny can be implemented on an OpenVG implementation. However, when more precisely examined, OpenVG lacks a few SVGTiny features including scene graphs, parsing, animation, linking and scripting features. Thus, these features should be implemented separately. In any case, the OpenVG can provide most features of SVG-Tiny, and thus, we aimed to implement the OpenVG engine to finally provide SVG functionalities in addition to the OpenVG features. The OpenVG group was formed on July 2004, and they released the OpenVG 1.0 specification on August 2005. Although the OpenVG reference implementation was also released at that time, the purpose of this reference implementation is only to show the feasibility of the official specification. Thus, they did not focus on its efficiency
to finally show disappointing performances. The first commercially available implementation is our AlexVG system, released on September 2005. Several OpenVG implementations are followed, including AmanithVG [23], ShivaVG [28], QtOpenVG [30], etc. Since all of them are based on other graphics libraries such as OpenGL, OpenGL ES and Qt, their commercial values are restricted. Additionally, most of them do not provide their detailed data such as the pass rate on the conformance test suites and performance measures. More detailed comparison with these other OpenGL implementations will be shown in Section 4. 2.2. SVG and SVG-Tiny In 1999, WWW consortium started to develop an open format named SVG (scalable vector graphics). The official SVG 1.0 specification provides graphics, animation, and some more advanced features. The current SVG 1.2 specification consists of SVG full version and SVGTiny version which is optimized for embedded systems [38,39]. The 3GPP (3rd generation partnership project) selected SVG-Tiny as the standard MMS (multimedia messaging service) format for the next generation mobile phone platforms [34]. 2.3. Java specification requests In addition to SVG, several Java Specification Requests (JSRs) are also closely related to OpenVG [16]. In the first place, JSR226 [12] is the Java Binding for SVG-Tiny 1.1. Later, new JSR projects related to SVG and OpenVG are also started. JSR271 [13] 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) [33]. JSR287 [14] includes functions for advanced immediate-mode rendering APIs, 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 scaleable vector graphics functions. OpenVG workgroup from the Khronos Group starts to define a new OpenVG specification, to newly include supports for flash players and font rendering. The next version of OpenVG will cover all major rendering functions of JSR271 and JSR287. 2.4. Our implementation strategy When more than two graphics standards provide similar features, it is usually more efficient to implement both of them simultaneously [6]. During their implementation, it is better to integrate their characteristics from the early design stages. Later, it is important to fulfill both standard specifications and also to efficiently implement both of them. In the case of OpenVG and SVG-Tiny, we can easily establish their relationships. When there is an existing OpenVG implementation, it is intuitive and relatively easy to implement SVG-Tiny applications, based on the existing OpenVG facilities. Theoretically, most of SVGTiny rendering features can be achieved by the OpenVG rendering pipeline, whose rendering performance may be even better with smaller code size. The reduced footprints for the SVG-Tiny applications would be another benefit. In the next section, we will show the details of developing an OpenVG engine with SVG-Tiny support. 3. AlexVG: our OpenVG implementation In this section, we will represent AlexVG core facilities, and then show the SVG-Tiny support features which act as an extra layer over the core facilities.
H. Lee, N. Baek / Computer Standards & Interfaces 31 (2009) 661–668
Fig. 1. Overall structure of OpenVG.
3.1. AlexVG implementation We started from analyzing the overall structure of OpenVG for its full implementation. As shown in Fig. 1, OpenVG has a device controller layer, named EGL [17], just above the hardware devices.
663
The OpenVG itself consists of the Engine (core), API (language bindings) and Utilities. Over the OpenVG system, there may be applications based on BREW [29], Java [32], etc. Since OpenVG isolates device-dependent parts into its 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 [19]. 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 stages. However, the overall and fundamental architecture is not stained. The overview of the OpenVG pipeline is represented in Fig. 2. As shown in the official specification [19], this figure is focusing on the various steps to draw a thick, dashed line into a scene using a radial gradient paint. See the OpenVG specification [19] for more details on these processing stages. From the viewpoint of the application programmers, they use OpenVG APIs to specify output paths or drawing parameters, as the
Fig. 2. OpenVG rendering pipeline.
664
H. Lee, N. Baek / Computer Standards & Interfaces 31 (2009) 661–668
Fig. 3. Images selected from our Alex VG demonstration programs.
actions in the stage 1. Later, the drawing functions such as vgDrawPath (⋯) and vgDrawImage(⋯) are invoked, and the graphics engine converts the object and its drawing parameters into detailed bitmap information, through stages 2 to 7. In stage 8, this new source image is finally synthesized into the current output image. Through repeating all these steps for each object, we get the final image. We implemented the AlexVG engine using the C programming language. Our vector graphics engine performs object-based processing for the paths and objects in stages 1 to 3, while it also does fragment-based (or pixel-based) processing for each pixel of the objects, in stages 4 to 8. For more efficiency, we use fixed-point number representation of Q16.16 [5,8] for the internal calculations of real numbers. Since most low-level CPU cores used in embedded systems are basically integer processors, all floating-point operations should be simulated using integer arithmetic. Using fixed-point arithmetic instead of floating point shows remarkable performance improvements on these small-scale CPUs. See [5] and [8] for more details on the fixed-point processing. Through implementing our AlexVG engine, we solved lots of implementation issues, and finally our implementation has some distinguishable features including the following: • cost-effective implementation: AlexVG engine and its companion VGU (OpenVG Utility library) provide all SVG-Tiny features and more, in addition to its original OpenVG facilities. It is a costeffective way of providing OpenVG, SVG, and maybe other JSRs in the near future. • portable and configurable implementation: Our modular approach enables us to isolate system-dependent code segments in specific modules. Since our AlexVG engine does not require any specialized hardware, we can easily port this engine to various embedded systems including mobile phones, PDAs, PMPs (portable multimedia players) and set-top boxes. It is also possible to let it be integrated
into existing software platforms such as BREW [29] and WIPI [40]. It also enables us to control the overall performance between the visual quality and its processing speed, which is more important to embedded systems.
Fig. 4. Overall architecture of AlexVG player B110.
H. Lee, N. Baek / Computer Standards & Interfaces 31 (2009) 661–668
• accelerated algorithms: Since the geometric algorithms in OpenVG are somewhat complex and have different viewpoints from traditional graphics algorithms, we totally re-designed some algorithms to achieve overall accelerations. Through the AlexVG implementation process, we tested the engine itself 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 platforms. Fig. 3 shows some examples from our plentiful demonstration programs. 3.2. AlexVG player B110: our SVG-Tiny player To show the correctness and benefits of our implementation strategy, we implemented an SVG-Tiny 1.1 player, named AlexVG player B110, on our AlexVG system, as shown in Fig. 4. This application layer 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. This program shows an example for the efficient and cost-effective way of implementing SVG-Tiny applications on an OpenVG implementation.
665
Fig. 5 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 imagerelated 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 bgN element, its child element blineN is drawn with this stroke color, when the blineN element has no specific stroke color attribute. For all these inheritance processing, we need an internal attribute stack. For the container elements such as bsvgN and bgN 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 parents. 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
Fig. 5. Global view of AlexVG player B110 internal processing.
666
H. Lee, N. Baek / Computer Standards & Interfaces 31 (2009) 661–668
Fig. 6. Snapshots for sample SVG-Tiny media files (© Edik Mitgartz).
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(⋯) and vgDrawImage(⋯). When the animation is still continuing, the rendering process is repeated, as shown in Fig. 5. Overall process of AlexVG player B110 is now implemented and commercially available for various platforms. Fig. 6 shows a few samples from the various SVG documents used for feature tests of our AlexVG player B110. 4. Implementation results To analyze our implementation results, we checked its correctness and performance behaviors. For the correctness, the official conformance test suites may provide good measures. The test suites consist of a set of programs which test how exactly a specific implementation provides the official OpenVG specification. Our AlexVG implementation shows a 100% pass rate for the official conformance test suites, and thus, it is possible to claim that our implementation correctly provides all the officinal OpenVG features. In contrast, other OpenVG implementations are lacking this kind of conformance test pass ratios. Only one OpenVG implementation [21] claims that their implementation shows about 73% pass rate. From the developer's point of view, the conformance test pass rate would be a good measure to select an OpenVG implementation. Additionally, developers also need to check the performance of candidate OpenVG implementations. Most of other OpenVG impleTable 1 Performance tests for Tiger and Calder. Program name
Tiger Calder
Rendering time
Ratio
AlexVG
Ref. Imp.
1 ms b 1 ms
184 ms 17 ms
1:122.9 1:172.0
mentations are based on the underlying graphics libraries such as OpenGL, OpenGL ES, Qt, etc. Furthermore, some of them are only executable for specific hardware or specific operating systems, to finally prevent overall comparisons. Since we cannot access the source code of some implementations, comparisons between the real performances are impossible. The reference implementation from the Khronos group provides all the source codes and is executable in typical PC windows environments. Thus, as a typical performance comparison, we compare the execution times of AlexVG and official reference implementation on a Windows XP machine. The final execution times on an Intel Core2 6600 2.4 GHz CPU with 2 GB RAM are summarized in Table 1. The Tiger test program originated from the famous example for PostScript test suites and converted into an OpenVG program. Another example, Calder is designed to display a fine artwork. As shown in Table 1, the execution speed of AlexVG is far much faster than 122 times in comparison with official reference implementation. This result is as expected since the official reference implementation focuses on the feasibility of the OpenVG specification rather than any efficiency or optimized behaviors.
Table 2 Execution results for AlexVG test programs. Program name
Code size
Data size
Frames per second
Map Tiger Font Wave Filter Flake Lady
3.5 2.5 3.4 2.0 2.4 2.0 3.8
37.0 KB 72.0 KB 12.0 KB 4.0 KB 308.0 KB 309.0 KB 30.0 KB
2.2 1.8 20.0 7.1 0.4 4.3 4.0
KB KB KB KB KB KB KB
Snapshots of program displays are shown in Fig. 3. Code size: pure executable code size. Data size: pure data size for path and images.
H. Lee, N. Baek / Computer Standards & Interfaces 31 (2009) 661–668 Table 3 Execution results for SVG-Tiny media files. Media file name
File size
Frames per second
guitar.svg lamb.svg picasso.svg retro.svg spud.svg
18.6 KB 38.1 KB 109.0 KB 14.7 KB 5.4 KB
30.8 16.0 5.6 44.4 100.0
Snapshots of the media files are shown in Fig. 6.
667
Since all the standards directly-related to OpenVG, including SVG, JSR226, JSR271 and JSR287, tend to be integrated into a unified standard, AlexVG would be also improved along their changes. Recently, it is reported that Flash programs can also be integrated into the OpenVG framework. Thus, in a long term period, AlexVG will be an integrated programming environment supporting most twodimensional graphics standards and its applications. For more technical details and/or questions, visit our official AlexVG web site [9]. Acknowledgements
In the previously mentioned OpenVG implementation of [21], they also reported that their implementation is about 2 to 3 times faster than the official reference implementation. Especially, in the case of the Tiger example, they used the same test program and finally got exactly 2.02 times speed-up. Although we failed to get any other performance test results for other implementations, it distinctly shows the speed gaps between our AlexVG implementation and others. Since AlexVG system mainly targets embedded systems including mobile phones, we did a variety of performance tests on the ARM architectures, which are the most widely used small-scale CPUs. Table 2 shows our experimental results on ARM9 210 MHz CPU with 240 × 320 color LCD display. As shown in this table, AlexVG achieves enough number of frames per second for various kinds of demonstrative and real-world application programs. To measure the performance behavior of our SVG-Tiny player, AlexVG player B110, we use the SVG-Tiny media files shown in Table 3. We measured the elapsed time to display these media files on the ARM9 216 MHz CPU with 240 × 320 color LCD display. As shown in Table 3, the frame rates are high enough to be used for real-world SVG files. In fact, our AlexVG player B110 is actually used as SVG-Tiny players on commercial mobile phones. 5. Conclusion In this paper, we represented AlexVG, an OpenVG system as the fundamental part of a two-dimensional scalable vector graphics environment, where OpenVG and SVG-Tiny are fully supported. Most previous OpenVG implementations are based on three-dimensional graphics libraries such as OpenGL [31] or OpenGL ES [20] as its underlying layer [11,23]. In contrast, our AlexVG engine focuses on the efficient and cost-effective implementation for mobile and embedded devices with limited resources, and thus, we implemented a fully independent engine. Our AlexVG engine has been commercially available since 2005 [10]. The outstanding points of our AlexVG system can be summarized as follows: • An independent solution for the OpenVG full set: While other OpenVG implementations rely on other graphics libraries such as OpenGL and OpenGL ES, our AlexVG is a completely independent solution which directly handles the hardware buffers. • A highly tuned system especially for embedded systems: The final footprint of AlexVG has less than 120 KB code size for ARM CPUs and about 30 KB static frame buffer for QVGA (240 × 320) resolutions. This small footprint delivers various vector graphics facilities even on mid-tier embedded systems with strictly limited resources. • A fully-tested commercial product: AlexVG has passed 100% of official OpenVG conformance test suites and shipped on commercial mobile phones since 2006. Our AlexVG is already in its stabilized state and a fully-tested commercial system. • Simultaneous support for SVG-Tiny features: Our AlexVG system had aimed at a cost-effective implementation, and included SVG-Tiny features at its design stage. These SVG-Tiny features are satisfying the SVG-Tiny conformance test [37] and we also provide various application programs based on it, including our SVG-Tiny player, AlexVG player B110.
This work was supported by grant No. RTI04-03-02 from the Regional Technology Innovation Program of the Ministry of Knowledge Economy(MKE) of South Korea. The authors would like to thank Mr. Joon Young Lee and Ms. Aekyoung Oh for their contributions to the early stage implementations. References [1] Adobe Systems Inc., PostScript Language Reference Manual, 3rd ed. AddisonWesley, 1999. [2] Adobe Systems Inc., PDF Reference, 6th edition, 2007 http://www.adobe.com/ devnet/acrobat/pdfs/pdf reference.pdf. [3] Adove Systems Inc., SVG zone, http://www.adobe.com/svg/. [4] Apple Inc., Safari 3 home page, http://www.apple.com/safari/. [5] ARM, Fixed Point Arithmetic on the ARM, Application Note 33, ARM, 1996. [6] N. Baek, S.R. Maeng, A unified reference model for CGM/CGI and its implementation, Computer Standards & Interfaces 18 (5) (1997) 451–467. [7] T. Evans, Introducing Macromedia Flash Lite 1.1, Macromedia Developer Center, 2004. [8] D. Hough, Applications of the proposed IEEE-754 standard for floating point arithmetic, IEEE Computer 14 (3) (1981) 70–74. [9] Huone Inc., AlexVG home page, http://www.alexvg.com/. [10] Huone Inc., Huone home page, http://www.hu1.com/. [11] Hybrid Graphics Ltd., OpenVG reference implementation, http://www.hybrid.fi/ main/extra/openvg ri.php. [12] Java Community Process, JSR226: Scaleable 2D Vector Graphics API for J2ME, Java Community Process, 2005. [13] Java Community Process, JSR271: Mobile Information Device Profile 3, Java Community Process, 2006. [14] Java Community Process, JSR287: Scaleable 2D Vector Graphics API 2.0 for Java ME, Java Community Process, 2006. [15] Khronos Group, Khronos group home page, http://www.khronos.org/. [16] Khronos Group, OpenVG home page, http://www.khronos.org/openvg/. [17] Khronos Group, Native Platform Graphics Interface 1.2, Khronos Group, 2005. [18] Khronos Group, OpenVG Conformance Test Process, OpenVG Workgroup, 2005. [19] Khronos Group, OpenVG Specification, version 1.0.1, Khronos Group, 2005. [20] Khronos Group, OpenGL ES Common/Common-Lite Profile Specification, Version 1.1, Khronos Group, 2007. [21] S.-Y. Lee, S. Kim, J. Chung, B.-U. Choi, Salable vector graphics (openVG) for creating animation image in embedded systems, Knowledge-based Intelligent Inform. and Eng. Sys., 11th Int'l Conf.(KES 2007), 2007. [22] Macromedia Inc., Macromedia flash developer center, http://www.adobe.com/ devnet/flash. [23] Mazatech, AmanithVG home page, http://www.amanithvg.com/. [24] Mozilla, FireFox 2 home page, http://www.firefox.com/. [25] Mozilla Developer Center, SVG in FireFox, http://developer.mozilla.org/en/docs/ SVG in FireFox. [26] Opera Software, Opera browser, http://www.opera.com/. [27] Opera Software, SVG in Opera, http://www.opera.com/products/desktop/svg/. [28] Pixel Infinity, ShivaVG: open-source ANSI C OpenVG, http://ivanleben.blogspot. com/2007/07/shivavg-open-source-ansi-c-openvg.html. [29] Qualcomm, BREW home, http://brew.qualcomm.com/. [30] Z. Rusin, QtOpenVG, http://zrusin.blogspot.com/2007/01/openvg 116899762231694078. html. [31] M. Segal, K. Akeley, The OpenGL Graphics System: A Specification, Version 2.1, Silicon Graphics, 2006. [32] Sun Microsystems Inc., Java 2D API home page, http://java.sun.com/products/ java-media/2D. [33] Sun Microsystems Inc., Mobile information device profile(MIDP), http://java.sun. com/products/midp/. [34] The 3rd Generation Partnership Project, 3GPP home page, http://www.3gpp.org/. [35] Trolltech, Qt cross-platform application framework, http://trolltech.com/products/qt/. [36] W3C, Scalable vector graphics, http://www.w3.org/Graphics/SVG/. [37] W3C, Scalable vector graphics(SVG) test suite, http://www.w3.org/Graphics/ SVG/Test/. [38] W3C, Scalable Vector Graphics(SVG) Full 1.2 Specification, W3C Recommendation, 2006. [39] W3C, Scalable Vector Graphics(SVG) Tiny 1.2 Specification, W3C Recommendation, 2006. [40] WIPI Forum, WIPI home, http://wipi.or.kr/English/.
668
H. Lee, N. Baek / Computer Standards & Interfaces 31 (2009) 661–668 Hwanyong Lee is currently Chief Research Officer of HUONE Inc., Korea. He received his B.A. in Computer Science from Korea Advanced Institute of Science and Technology (KAIST) in 1990 and M.S. in Computer Engineering from Pohang University of Science and Technology (POSTECH) in 1992. His research interests include computer graphics, embedded system software and game design and development. Since 2004, he has been developing graphics software for mobile devices as Chief Research Officer of HUONE Inc.
Nakhoon Baek is currently an associate professor in the School of Electrical Engineering & Computer Science at Kyungpook National University, Korea. He received his B.A., M.S., and Ph.D. in Computer Science from Korea Advanced Institute of Science and Technology (KAIST) in 1990, 1992, and 1997, respectively. His research interests include graphics standards, graphics algorithms and real-time rendering. He had implemented an in-house version of CGM/CGI graphics standards in the late 1990s, for a telephone company in Korea. Since 2005, he has been co-working with the graphics team in HUONE Inc. to commercially implement a set of graphics standards for embedded systems including OpenVG, OpenGL ES and Collada.
Contents lists available at ScienceDirect
Computer Standards & Interfaces j o u r n a l h o m e p a g e : w w w. e l s e v i e r. c o m / l o c a t e / c s i
AlexVG: An OpenVG implementation with SVG-Tiny support Hwanyong Lee a, Nakhoon Baek b,⁎ a b
Huone Inc., Mobile Techno Bldg 6th Floor, Bok-Hyun-dong, Daegu 702-020, Republic of Korea School of EECS, Kyungpook National University, Daegu 702-701, Republic of Korea
a r t i c l e
i n f o
Article history: Received 21 August 2007 Received in revised form 24 May 2008 Accepted 28 June 2008 Available online 11 July 2008 Keywords: OpenVG SVG-Tiny Vector graphics library Commercial implementation
a b s t r a c t Embedded systems and web browsers have started to provide two-dimensional vector graphics features, to finally support scalability of graphics outputs, while traditional graphics systems have focused on the raster and bitmap operations. Nowadays, SVG and Flash are actively used and OpenVG from Khronos group plays the role of a de facto low-level API standard to support them. In this paper, we represent the design and implementation process and the final results of the first commercial OpenVG implementation, AlexVG. From its design stage, our implementation aims at the cooperation with SVG-Tiny, another de facto standard for embedded systems. Currently, our overall system provides not only the OpenVG core features but also a variety of OpenVG application programs and SVG-Tiny media file playing capabilities. For the conformance with the standard specifications, our system completely passed the whole OpenVG conformance test suites and the graphics output portions of the SVG-Tiny conformance test suites. From the performance point of view, we focused on the efficiency and effectiveness especially on the mobile phones and embedded devices with limited resources. As the result, it showed impressive benchmarks on the small-scale CPUs such as ARMs, even without neither any other libraries nor acceleration hardware. We had started commercial services of our AlexVG products since September 2005, and successfully entered the retail market with a good deal of mobile phones up to the present time. © 2008 Elsevier B.V. All rights reserved.
1. Introduction Recently, two-dimensional graphics systems are focusing on the scalable vector graphics features, in addition to the traditional raster graphics and image handling features [7,39]. Vector graphics outputs may preserve the final image quality without degradations such as jaggy effects due to image scaling. Thus, it has the capability of providing the same image quality regardless of display device sizes or resolutions. This feature is much valuable for downsizing usual graphics outputs onto small-size embedded systems. Currently, Macromedia Flash [22] and SVG (scalable vector graphics) [36] are widely used as the vector graphics solutions for the desktop PCs. Especially for the web environment, SVG becomes one of the most important features, and now we have lots of SVG applications. SVG is originally a language to describe two-dimensional graphics outputs and graphical applications in XML [38,39]. For web browsers, thus, it is natural to show SVG contents directly on the web pages as they did in these days. In most web browsers including FireFox [24], Safari [4] and Opera [26], SVG viewers are naturally embedded [25,27]. In contrast, Internet Explorer requires a plug-in to view SVG contents. Currently, the Adobe SVG plug-in [3] is one of the most well-known ones.
⁎ Corresponding author. E-mail addresses: [email protected] (H. Lee), [email protected] (N. Baek). 0920-5489/$ – see front matter © 2008 Elsevier B.V. All rights reserved. doi:10.1016/j.csi.2008.06.010
Another trend in the commercial computer graphics area is the emphasis on embedded systems. Getting more powerful hardware platforms, mobile systems are equipped with more advanced graphics applications including GUI (graphics user interface) managers, multimedia messaging services, GPS navigations, multimedia file players, etc. Traditional graphics systems based on the bitmap and raster operations are hard to support these new kinds of applications. Vector graphics features are needed to overcome these limitations, and now Flash-Lite [7] and SVG-Tiny [39] are introduced as their optimized versions for the small-scale embedded systems. SVG-Tiny originally targets resource-limited devices and nowadays it is an essential part for the third generation mobile phones. In contrast to this downsizing strategy starting from existing PCscale solutions, OpenVG was initiated as a native graphics standard for embedded systems. Khronos Group [15] is a member-funded industry consortium focused on the creation of open standard, royalty-free APIs. At this time, Khronos Group provides various graphics standards for embedded systems. Among them, OpenVG [16,19] is established to support two-dimensional vector graphics output on the embedded systems. OpenVG is a royalty-free, cross-platform API that provides low-level interfaces for vector graphics libraries such as Flash and SVG. In this paper, we present a commercial OpenVG implementation, AlexVG. Our AlexVG system was officially released in September 2005, as the first commercial OpenVG implementation [10]. The AlexVG system has successfully entered the commercial market
662
H. Lee, N. Baek / Computer Standards & Interfaces 31 (2009) 661–668
through being adopted for mobile phones by Samsung Electronics since 2006. We also achieved its cost-effectiveness through simultaneously supporting both of OpenVG and SVG-Tiny standards. Since the official release of OpenVG 1.0 specification in August 2005, there have been several OpenVG implementations [11,23,28,30]. However, almost all of them are based on other graphics libraries including OpenGL [31], OpenGL ES [20] and Qt [35]. Thus, they are hard to achieve software independence, and may not be free from royalty problems, which may be serious restrictions on their commercial uses. In contrast, our implementation works as a full software implementation, which directly accesses the hardware buffers, to be cost-effectively adopted by most hardware platforms without neither any major modifications nor special hardware supports. From the cost-effective point of view, it is more natural to support similar or mutually dependent graphics standards at the same time. Since one of the authors already has the experience of simultaneously implementing two international graphics standards [6], we aimed to simultaneously implement both of OpenVG and SVG-Tiny features. This strategy enables us to provide both features with less than 120 KB code space for ARM CPUs. So, we can deliver the various vector graphics outputs even on mid-tier mobile phones. The next section of this paper presents an overview of OpenVG and its related standards. Details of design and implementation issues on our AlexVG system are followed in Section 3. Implementation results and performance analysis are presented in Section 4. Finally, we conclude this paper in Section 5. 2. Background and previous works This section provides specific guidance for OpenVG and its related standard specifications including SVG, SVG-Tiny, JSRs etc. Additionally, other OpenVG implementations and their comparisons to our AlexVG implementation are presented. 2.1. OpenVG and its implementations OpenVG is an open standard for the platform-independent hardware-based acceleration of two-dimensional vector graphics systems. According to its official specification, OpenVG provides a drawing model similar to those of existing two-dimensional drawing API's and formats, such as PostScript [1], PDF [2], Flash [22], Java2D [32] and SVG [38,39]. As a kind of implementation guidelines to OpenVG developers, Khronos group provides the OpenVG conformance test suites [18]. This conformance test suites are a good indication to show how much an OpenVG implementation satisfies the official OpenVG specification. A proper implementation should show completely 100% pass rate on the conformance test suites. As the developers of the first commercial OpenVG implementation, we also officially participate in the development of these OpenVG conformance test suites. OpenVG is originally intended to support all drawing features required by the SVG-Tiny 1.2 renderer [16,19]. From the viewpoint of SVG, OpenVG covers most of SVG-Tiny rendering functions, and thus, SVG-Tiny can be implemented on an OpenVG implementation. However, when more precisely examined, OpenVG lacks a few SVGTiny features including scene graphs, parsing, animation, linking and scripting features. Thus, these features should be implemented separately. In any case, the OpenVG can provide most features of SVG-Tiny, and thus, we aimed to implement the OpenVG engine to finally provide SVG functionalities in addition to the OpenVG features. The OpenVG group was formed on July 2004, and they released the OpenVG 1.0 specification on August 2005. Although the OpenVG reference implementation was also released at that time, the purpose of this reference implementation is only to show the feasibility of the official specification. Thus, they did not focus on its efficiency
to finally show disappointing performances. The first commercially available implementation is our AlexVG system, released on September 2005. Several OpenVG implementations are followed, including AmanithVG [23], ShivaVG [28], QtOpenVG [30], etc. Since all of them are based on other graphics libraries such as OpenGL, OpenGL ES and Qt, their commercial values are restricted. Additionally, most of them do not provide their detailed data such as the pass rate on the conformance test suites and performance measures. More detailed comparison with these other OpenGL implementations will be shown in Section 4. 2.2. SVG and SVG-Tiny In 1999, WWW consortium started to develop an open format named SVG (scalable vector graphics). The official SVG 1.0 specification provides graphics, animation, and some more advanced features. The current SVG 1.2 specification consists of SVG full version and SVGTiny version which is optimized for embedded systems [38,39]. The 3GPP (3rd generation partnership project) selected SVG-Tiny as the standard MMS (multimedia messaging service) format for the next generation mobile phone platforms [34]. 2.3. Java specification requests In addition to SVG, several Java Specification Requests (JSRs) are also closely related to OpenVG [16]. In the first place, JSR226 [12] is the Java Binding for SVG-Tiny 1.1. Later, new JSR projects related to SVG and OpenVG are also started. JSR271 [13] 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) [33]. JSR287 [14] includes functions for advanced immediate-mode rendering APIs, 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 scaleable vector graphics functions. OpenVG workgroup from the Khronos Group starts to define a new OpenVG specification, to newly include supports for flash players and font rendering. The next version of OpenVG will cover all major rendering functions of JSR271 and JSR287. 2.4. Our implementation strategy When more than two graphics standards provide similar features, it is usually more efficient to implement both of them simultaneously [6]. During their implementation, it is better to integrate their characteristics from the early design stages. Later, it is important to fulfill both standard specifications and also to efficiently implement both of them. In the case of OpenVG and SVG-Tiny, we can easily establish their relationships. When there is an existing OpenVG implementation, it is intuitive and relatively easy to implement SVG-Tiny applications, based on the existing OpenVG facilities. Theoretically, most of SVGTiny rendering features can be achieved by the OpenVG rendering pipeline, whose rendering performance may be even better with smaller code size. The reduced footprints for the SVG-Tiny applications would be another benefit. In the next section, we will show the details of developing an OpenVG engine with SVG-Tiny support. 3. AlexVG: our OpenVG implementation In this section, we will represent AlexVG core facilities, and then show the SVG-Tiny support features which act as an extra layer over the core facilities.
H. Lee, N. Baek / Computer Standards & Interfaces 31 (2009) 661–668
Fig. 1. Overall structure of OpenVG.
3.1. AlexVG implementation We started from analyzing the overall structure of OpenVG for its full implementation. As shown in Fig. 1, OpenVG has a device controller layer, named EGL [17], just above the hardware devices.
663
The OpenVG itself consists of the Engine (core), API (language bindings) and Utilities. Over the OpenVG system, there may be applications based on BREW [29], Java [32], etc. Since OpenVG isolates device-dependent parts into its 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 [19]. 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 stages. However, the overall and fundamental architecture is not stained. The overview of the OpenVG pipeline is represented in Fig. 2. As shown in the official specification [19], this figure is focusing on the various steps to draw a thick, dashed line into a scene using a radial gradient paint. See the OpenVG specification [19] for more details on these processing stages. From the viewpoint of the application programmers, they use OpenVG APIs to specify output paths or drawing parameters, as the
Fig. 2. OpenVG rendering pipeline.
664
H. Lee, N. Baek / Computer Standards & Interfaces 31 (2009) 661–668
Fig. 3. Images selected from our Alex VG demonstration programs.
actions in the stage 1. Later, the drawing functions such as vgDrawPath (⋯) and vgDrawImage(⋯) are invoked, and the graphics engine converts the object and its drawing parameters into detailed bitmap information, through stages 2 to 7. In stage 8, this new source image is finally synthesized into the current output image. Through repeating all these steps for each object, we get the final image. We implemented the AlexVG engine using the C programming language. Our vector graphics engine performs object-based processing for the paths and objects in stages 1 to 3, while it also does fragment-based (or pixel-based) processing for each pixel of the objects, in stages 4 to 8. For more efficiency, we use fixed-point number representation of Q16.16 [5,8] for the internal calculations of real numbers. Since most low-level CPU cores used in embedded systems are basically integer processors, all floating-point operations should be simulated using integer arithmetic. Using fixed-point arithmetic instead of floating point shows remarkable performance improvements on these small-scale CPUs. See [5] and [8] for more details on the fixed-point processing. Through implementing our AlexVG engine, we solved lots of implementation issues, and finally our implementation has some distinguishable features including the following: • cost-effective implementation: AlexVG engine and its companion VGU (OpenVG Utility library) provide all SVG-Tiny features and more, in addition to its original OpenVG facilities. It is a costeffective way of providing OpenVG, SVG, and maybe other JSRs in the near future. • portable and configurable implementation: Our modular approach enables us to isolate system-dependent code segments in specific modules. Since our AlexVG engine does not require any specialized hardware, we can easily port this engine to various embedded systems including mobile phones, PDAs, PMPs (portable multimedia players) and set-top boxes. It is also possible to let it be integrated
into existing software platforms such as BREW [29] and WIPI [40]. It also enables us to control the overall performance between the visual quality and its processing speed, which is more important to embedded systems.
Fig. 4. Overall architecture of AlexVG player B110.
H. Lee, N. Baek / Computer Standards & Interfaces 31 (2009) 661–668
• accelerated algorithms: Since the geometric algorithms in OpenVG are somewhat complex and have different viewpoints from traditional graphics algorithms, we totally re-designed some algorithms to achieve overall accelerations. Through the AlexVG implementation process, we tested the engine itself 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 platforms. Fig. 3 shows some examples from our plentiful demonstration programs. 3.2. AlexVG player B110: our SVG-Tiny player To show the correctness and benefits of our implementation strategy, we implemented an SVG-Tiny 1.1 player, named AlexVG player B110, on our AlexVG system, as shown in Fig. 4. This application layer 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. This program shows an example for the efficient and cost-effective way of implementing SVG-Tiny applications on an OpenVG implementation.
665
Fig. 5 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 imagerelated 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 bgN element, its child element blineN is drawn with this stroke color, when the blineN element has no specific stroke color attribute. For all these inheritance processing, we need an internal attribute stack. For the container elements such as bsvgN and bgN 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 parents. 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
Fig. 5. Global view of AlexVG player B110 internal processing.
666
H. Lee, N. Baek / Computer Standards & Interfaces 31 (2009) 661–668
Fig. 6. Snapshots for sample SVG-Tiny media files (© Edik Mitgartz).
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(⋯) and vgDrawImage(⋯). When the animation is still continuing, the rendering process is repeated, as shown in Fig. 5. Overall process of AlexVG player B110 is now implemented and commercially available for various platforms. Fig. 6 shows a few samples from the various SVG documents used for feature tests of our AlexVG player B110. 4. Implementation results To analyze our implementation results, we checked its correctness and performance behaviors. For the correctness, the official conformance test suites may provide good measures. The test suites consist of a set of programs which test how exactly a specific implementation provides the official OpenVG specification. Our AlexVG implementation shows a 100% pass rate for the official conformance test suites, and thus, it is possible to claim that our implementation correctly provides all the officinal OpenVG features. In contrast, other OpenVG implementations are lacking this kind of conformance test pass ratios. Only one OpenVG implementation [21] claims that their implementation shows about 73% pass rate. From the developer's point of view, the conformance test pass rate would be a good measure to select an OpenVG implementation. Additionally, developers also need to check the performance of candidate OpenVG implementations. Most of other OpenVG impleTable 1 Performance tests for Tiger and Calder. Program name
Tiger Calder
Rendering time
Ratio
AlexVG
Ref. Imp.
1 ms b 1 ms
184 ms 17 ms
1:122.9 1:172.0
mentations are based on the underlying graphics libraries such as OpenGL, OpenGL ES, Qt, etc. Furthermore, some of them are only executable for specific hardware or specific operating systems, to finally prevent overall comparisons. Since we cannot access the source code of some implementations, comparisons between the real performances are impossible. The reference implementation from the Khronos group provides all the source codes and is executable in typical PC windows environments. Thus, as a typical performance comparison, we compare the execution times of AlexVG and official reference implementation on a Windows XP machine. The final execution times on an Intel Core2 6600 2.4 GHz CPU with 2 GB RAM are summarized in Table 1. The Tiger test program originated from the famous example for PostScript test suites and converted into an OpenVG program. Another example, Calder is designed to display a fine artwork. As shown in Table 1, the execution speed of AlexVG is far much faster than 122 times in comparison with official reference implementation. This result is as expected since the official reference implementation focuses on the feasibility of the OpenVG specification rather than any efficiency or optimized behaviors.
Table 2 Execution results for AlexVG test programs. Program name
Code size
Data size
Frames per second
Map Tiger Font Wave Filter Flake Lady
3.5 2.5 3.4 2.0 2.4 2.0 3.8
37.0 KB 72.0 KB 12.0 KB 4.0 KB 308.0 KB 309.0 KB 30.0 KB
2.2 1.8 20.0 7.1 0.4 4.3 4.0
KB KB KB KB KB KB KB
Snapshots of program displays are shown in Fig. 3. Code size: pure executable code size. Data size: pure data size for path and images.
H. Lee, N. Baek / Computer Standards & Interfaces 31 (2009) 661–668 Table 3 Execution results for SVG-Tiny media files. Media file name
File size
Frames per second
guitar.svg lamb.svg picasso.svg retro.svg spud.svg
18.6 KB 38.1 KB 109.0 KB 14.7 KB 5.4 KB
30.8 16.0 5.6 44.4 100.0
Snapshots of the media files are shown in Fig. 6.
667
Since all the standards directly-related to OpenVG, including SVG, JSR226, JSR271 and JSR287, tend to be integrated into a unified standard, AlexVG would be also improved along their changes. Recently, it is reported that Flash programs can also be integrated into the OpenVG framework. Thus, in a long term period, AlexVG will be an integrated programming environment supporting most twodimensional graphics standards and its applications. For more technical details and/or questions, visit our official AlexVG web site [9]. Acknowledgements
In the previously mentioned OpenVG implementation of [21], they also reported that their implementation is about 2 to 3 times faster than the official reference implementation. Especially, in the case of the Tiger example, they used the same test program and finally got exactly 2.02 times speed-up. Although we failed to get any other performance test results for other implementations, it distinctly shows the speed gaps between our AlexVG implementation and others. Since AlexVG system mainly targets embedded systems including mobile phones, we did a variety of performance tests on the ARM architectures, which are the most widely used small-scale CPUs. Table 2 shows our experimental results on ARM9 210 MHz CPU with 240 × 320 color LCD display. As shown in this table, AlexVG achieves enough number of frames per second for various kinds of demonstrative and real-world application programs. To measure the performance behavior of our SVG-Tiny player, AlexVG player B110, we use the SVG-Tiny media files shown in Table 3. We measured the elapsed time to display these media files on the ARM9 216 MHz CPU with 240 × 320 color LCD display. As shown in Table 3, the frame rates are high enough to be used for real-world SVG files. In fact, our AlexVG player B110 is actually used as SVG-Tiny players on commercial mobile phones. 5. Conclusion In this paper, we represented AlexVG, an OpenVG system as the fundamental part of a two-dimensional scalable vector graphics environment, where OpenVG and SVG-Tiny are fully supported. Most previous OpenVG implementations are based on three-dimensional graphics libraries such as OpenGL [31] or OpenGL ES [20] as its underlying layer [11,23]. In contrast, our AlexVG engine focuses on the efficient and cost-effective implementation for mobile and embedded devices with limited resources, and thus, we implemented a fully independent engine. Our AlexVG engine has been commercially available since 2005 [10]. The outstanding points of our AlexVG system can be summarized as follows: • An independent solution for the OpenVG full set: While other OpenVG implementations rely on other graphics libraries such as OpenGL and OpenGL ES, our AlexVG is a completely independent solution which directly handles the hardware buffers. • A highly tuned system especially for embedded systems: The final footprint of AlexVG has less than 120 KB code size for ARM CPUs and about 30 KB static frame buffer for QVGA (240 × 320) resolutions. This small footprint delivers various vector graphics facilities even on mid-tier embedded systems with strictly limited resources. • A fully-tested commercial product: AlexVG has passed 100% of official OpenVG conformance test suites and shipped on commercial mobile phones since 2006. Our AlexVG is already in its stabilized state and a fully-tested commercial system. • Simultaneous support for SVG-Tiny features: Our AlexVG system had aimed at a cost-effective implementation, and included SVG-Tiny features at its design stage. These SVG-Tiny features are satisfying the SVG-Tiny conformance test [37] and we also provide various application programs based on it, including our SVG-Tiny player, AlexVG player B110.
This work was supported by grant No. RTI04-03-02 from the Regional Technology Innovation Program of the Ministry of Knowledge Economy(MKE) of South Korea. The authors would like to thank Mr. Joon Young Lee and Ms. Aekyoung Oh for their contributions to the early stage implementations. References [1] Adobe Systems Inc., PostScript Language Reference Manual, 3rd ed. AddisonWesley, 1999. [2] Adobe Systems Inc., PDF Reference, 6th edition, 2007 http://www.adobe.com/ devnet/acrobat/pdfs/pdf reference.pdf. [3] Adove Systems Inc., SVG zone, http://www.adobe.com/svg/. [4] Apple Inc., Safari 3 home page, http://www.apple.com/safari/. [5] ARM, Fixed Point Arithmetic on the ARM, Application Note 33, ARM, 1996. [6] N. Baek, S.R. Maeng, A unified reference model for CGM/CGI and its implementation, Computer Standards & Interfaces 18 (5) (1997) 451–467. [7] T. Evans, Introducing Macromedia Flash Lite 1.1, Macromedia Developer Center, 2004. [8] D. Hough, Applications of the proposed IEEE-754 standard for floating point arithmetic, IEEE Computer 14 (3) (1981) 70–74. [9] Huone Inc., AlexVG home page, http://www.alexvg.com/. [10] Huone Inc., Huone home page, http://www.hu1.com/. [11] Hybrid Graphics Ltd., OpenVG reference implementation, http://www.hybrid.fi/ main/extra/openvg ri.php. [12] Java Community Process, JSR226: Scaleable 2D Vector Graphics API for J2ME, Java Community Process, 2005. [13] Java Community Process, JSR271: Mobile Information Device Profile 3, Java Community Process, 2006. [14] Java Community Process, JSR287: Scaleable 2D Vector Graphics API 2.0 for Java ME, Java Community Process, 2006. [15] Khronos Group, Khronos group home page, http://www.khronos.org/. [16] Khronos Group, OpenVG home page, http://www.khronos.org/openvg/. [17] Khronos Group, Native Platform Graphics Interface 1.2, Khronos Group, 2005. [18] Khronos Group, OpenVG Conformance Test Process, OpenVG Workgroup, 2005. [19] Khronos Group, OpenVG Specification, version 1.0.1, Khronos Group, 2005. [20] Khronos Group, OpenGL ES Common/Common-Lite Profile Specification, Version 1.1, Khronos Group, 2007. [21] S.-Y. Lee, S. Kim, J. Chung, B.-U. Choi, Salable vector graphics (openVG) for creating animation image in embedded systems, Knowledge-based Intelligent Inform. and Eng. Sys., 11th Int'l Conf.(KES 2007), 2007. [22] Macromedia Inc., Macromedia flash developer center, http://www.adobe.com/ devnet/flash. [23] Mazatech, AmanithVG home page, http://www.amanithvg.com/. [24] Mozilla, FireFox 2 home page, http://www.firefox.com/. [25] Mozilla Developer Center, SVG in FireFox, http://developer.mozilla.org/en/docs/ SVG in FireFox. [26] Opera Software, Opera browser, http://www.opera.com/. [27] Opera Software, SVG in Opera, http://www.opera.com/products/desktop/svg/. [28] Pixel Infinity, ShivaVG: open-source ANSI C OpenVG, http://ivanleben.blogspot. com/2007/07/shivavg-open-source-ansi-c-openvg.html. [29] Qualcomm, BREW home, http://brew.qualcomm.com/. [30] Z. Rusin, QtOpenVG, http://zrusin.blogspot.com/2007/01/openvg 116899762231694078. html. [31] M. Segal, K. Akeley, The OpenGL Graphics System: A Specification, Version 2.1, Silicon Graphics, 2006. [32] Sun Microsystems Inc., Java 2D API home page, http://java.sun.com/products/ java-media/2D. [33] Sun Microsystems Inc., Mobile information device profile(MIDP), http://java.sun. com/products/midp/. [34] The 3rd Generation Partnership Project, 3GPP home page, http://www.3gpp.org/. [35] Trolltech, Qt cross-platform application framework, http://trolltech.com/products/qt/. [36] W3C, Scalable vector graphics, http://www.w3.org/Graphics/SVG/. [37] W3C, Scalable vector graphics(SVG) test suite, http://www.w3.org/Graphics/ SVG/Test/. [38] W3C, Scalable Vector Graphics(SVG) Full 1.2 Specification, W3C Recommendation, 2006. [39] W3C, Scalable Vector Graphics(SVG) Tiny 1.2 Specification, W3C Recommendation, 2006. [40] WIPI Forum, WIPI home, http://wipi.or.kr/English/.
668
H. Lee, N. Baek / Computer Standards & Interfaces 31 (2009) 661–668 Hwanyong Lee is currently Chief Research Officer of HUONE Inc., Korea. He received his B.A. in Computer Science from Korea Advanced Institute of Science and Technology (KAIST) in 1990 and M.S. in Computer Engineering from Pohang University of Science and Technology (POSTECH) in 1992. His research interests include computer graphics, embedded system software and game design and development. Since 2004, he has been developing graphics software for mobile devices as Chief Research Officer of HUONE Inc.
Nakhoon Baek is currently an associate professor in the School of Electrical Engineering & Computer Science at Kyungpook National University, Korea. He received his B.A., M.S., and Ph.D. in Computer Science from Korea Advanced Institute of Science and Technology (KAIST) in 1990, 1992, and 1997, respectively. His research interests include graphics standards, graphics algorithms and real-time rendering. He had implemented an in-house version of CGM/CGI graphics standards in the late 1990s, for a telephone company in Korea. Since 2005, he has been co-working with the graphics team in HUONE Inc. to commercially implement a set of graphics standards for embedded systems including OpenVG, OpenGL ES and Collada.