Keywords: SVG, MHP, Content, Transformation, Content Transformation
Anja Anke is a Master Student of Software Engineering at the Hasso-Plattner-Institute of the University of Potsdam. Before and during her studies she worked several years as a project developer, focused on application and database development and software testing.
Christian Hentschel is a graduate student of Computational Visualistics at the Otto-von-Guericke-Universität in Magdeburg. He recently received his Bachelor of Software Engineering at the Hasso-Plattner-Institute at the University Potsdam. His interests include information retrieval in image data, image processing and pattern recognition.
Mario Oschwald is a Master Student of Software Engineering at the Hasso-Plattner-Institute of the University of Potsdam. Before going back to university he worked several years as a UNIX system administrator and had a good time studying philosophy and mathematics at the University of Frankfurt/M.
Florian Kirsch works as Software Engineer at Mercury Computer Systems in Berlin. He is a Ph.D. candidate at the Hasso-Plattner-Institute of the University of Potsdam. His research interests include real-time rendering, multi-pass rendering algorithmus, CSG rendering, and scene graph technology. He studied Mathematics and Computer Science and received his diploma from the University of Münster.
Marc Nienhaus is a Ph.D. candidate and research assistant at the Hasso-Plattner-Institute of the University of Potsdam. His research interests include real-time rendering, non-photorealistic rendering, multimedia content creation systems, and depiction strategies for symbolizing dynamics. He studied Mathematics and Computer Science, received his diploma from the University of Münster, and worked as a software engineer focusing on 3D computer graphics. Marc is a student member of ACM and IEEE.
The Multimedia Home Platform (MHP) is an emerging standard for broadcasting and executing interactive television applications. In this paper, we present SVG²MHP, a content transformation system taking a Scalable Vector Graphics (SVG) file as input and transforming it into a self contained Java Xlet for deployment on MHP enabled TV sets. The main benefit of SVG²MHP is to enable visual prototyping and rapid application development techniques for MHP application designers and to overhaul the fact that, up to now, MHP application development implies a time-consuming Java programming task. In contrast, SVG as input format allows graphics designers to easily create MHP applications using well-known authoring software.
2.1 MHP application development
2.2 Methods for content creation
2.3 Restrictions of MHP
3. Architecture and Design Decisions
3.1 Application Transport Limitations
3.2 Hardware Limitations
3.3 Software Limitations
3.4 Graphics Limitations
3.5 Architecture Overview
3.5.1 The Pipeline
4. Running SVG²MHP
4.1 A simple example
4.2 Some practical examples
5. Conclusions and Prospect
Appendix 1. Rendering Speed of an STB
The Multimedia Home Platform (MHP) is an international standard for broadcasting applications and deploying them on end users TV sets via Digital Video Broadcasting (DVB). It was approved in February 2000 by the DVB Project, “a consortium of over 260 broadcasters, manufacturers, network operators, software developers and regulatory bodies" . With the ongoing digitalization of television (by 2010 all of German TV broadcast will be purely digital) MHP will be the foundation of interactive television in Europe.
MHP currently specifies two types of application to be executed on an end user's DVB receiver, the Set Top Box (STB). The first group are DVB-HTML applications, a set of HTML pages based on a modularized version of XHTML 1.1. This was introduced in the later MHP 1.1 standard and therefore has been of minor importance until now.
The far more popular class are the DVB-J (DVB-Java) applications. Written in Java 1.1 using the MHP API they consist of a set of class files that are broadcast with a TV program. DVB-Java applications are known as 'Xlets'. The concept of Xlets is similar to the concept of applets for web pages. Like applets, the Xlet interface allows an external source (the Application Manager in the terms of an MHP receiver) to start and stop an application upon the TV viewers request. This is typically done by pressing the appropriate remote control button.
Xlets are per design monolithic applications that incorporate application logic as well as input and output handling in a single class. This of course is cumbersome in a productive environment, where graphical interface design and programming are usually done by different persons. In the fast moving world of television, Xlets need to be developed in short time and in large numbers, once people start to expect accompanying applications to their TV experience. This, however, is difficult when all these Xlets would have to be hand coded. Programming is error prone and programming under time constraints even more so. Programming errors witnessed by millions of viewers are particularly embarrassing. For Xlets it is therefore essential that their code is robust, stable and failsafe.
In this paper, we present a content transformation system for generating Xlets: SVG²MHP. SVG²MHP uses the Scalable Vector Graphics format for content description and addresses all of the mentioned issues:
SVG²MHP not only has a real world utility in the domain of MHP application development. It also serves as a prime example of how proven and powerful technologies in one domain (SVG in 2D vector graphics and XML as its markup language) can help bootstrap the emerging technologies in another domain (MHP applications broadcast to a TV set via DVB).
In the following chapters we will further elaborate on the motivation and goals behind SVG²MHP followed by an overview of its architecture and the design decisions behind it. We will give some brief examples of generated Xlets and conclude with a description of SVG²MHP's capabilities and development status. Finally we will give a small prospect of the project's future.
When writing code for Xlets, a developer can use the expressiveness of the Java programming language. However, this turns out to be a true obstacle for developing applications for a rapidly changing media such as TV. In this area applications are mainly content driven, tend to have a short lifetime and a very low degree of reusability. For multimedia application development in other domains, such as interactive web content with Flash, this problem was identified a long time ago. Cutting down development time and thus being able to deliver solutions fast has led to broad use of techniques such as graphical user interface builders  and authoring software .
In Java 1.1 only very low level graphic primitives are available, hence the programmer is required to implement a high level abstraction to user interfaces separately for every Xlet. Hand-coding graphical elements and user interfaces, the de facto way of programming MHP applications, is far away from what is considered rapid application development. This fact not only highly increases the time to market for interactive TV applications. Furthermore it means a significant shift away from the traditional division of labor in producing multimedia applications: the visual components are created by designers – experts in interface ergonomics and layout – who pass them to software developers confident with appropriate programming languages. They embed the given interface design in the desired program context and develop the underlying logic. Considering today’s MHP application development either the designer has to be trained in Java programming or the software developer, fluent with the programming language, has to be an expert in interface design – neither of which is reasonable.
Finally, handwritten code tends to be very error-prone. Thorough testing to prevent broadcast Xlets from crashing would further increase the development time and has to be re-done for every created Xlet.
We found two suitable approaches for solving this dilemma. The idea behind both is to facilitate MHP application development by generating the Java code behind the graphical components of the Xlets. If the visible elements are no longer needed to be written by hand, this would not only facilitate visual prototyping but also it should permit to pass the creation of visual components of MHP applications back to the designers. The code necessary for application control will still remain in the hands of programmers. Ultimately, generated code will be error-free which again significantly reduces development time by cutting down on testing.
The first approach we identified is probably the most obvious one. For almost every digital media content there typically exists a multitude of authoring systems, which facilitate content production. For binary formats, this software of course is essential. But even for textual media representation formats such as HTML authoring software is very popular. These systems generate code by wrapping functionality in user interface elements (e.g. a square is drawn by simply clicking on the appropriate button in the authoring system). One could easily imagine an authoring system for MHP applications that generates the Xlet code. In fact such systems already exist (e.g. Cardinal Systems' Studio  ).
In a second approach the Java code would be generated as well. However, the base for the code generator is not formed by an authoring system but a different description language, expressive enough to easily cover the graphical elements of an MHP application. Preferably, this language would be extensible, allowing the seamless integration of MHP specific markup to tag DVB stream events, remote control buttons, video position etc. It should also be computer parsable and writable allowing for automatic content manipulation needed for a dynamic medium as TV. Finally, the language preferably should be an accepted and deployed industry standard since this would mean a significant aid to content developers: Designers will already be familiar with the language properties and, even more importantly, well-known authoring software the designer is possibly already familiar with will be readily available. In this way, MHP application development could hit the ground running which tremendously would influence the acceptance and proliferation of this new technology. For the mentioned advantages we decided to follow the second approach.
When looking for an appropriate language to describe multimedia content, we quickly came across the Scalable Vector Graphics format. SVG was intended to offer an open standard for describing static and animated two-dimensional vector graphics. It offers different kinds of graphic objects needed to develop user interfaces and graphic-driven applications, such as rectangles, circles, straight lines and curves. It allows the use of raster graphics images and the embedding of text. Objects can be styled, transformed and allow registration of event handlers to support interactivity. SVG offers declarative animations by means of SMIL and supports scripting languages to define the underlying application logic. Being an XML language, SVG is highly extensible by adding new namespaces and is therefore able to be adapted to the special needs of TV targeted applications. Similar to Flash  , it is perfectly suited for true multimedia applications but in contrary to Flash it is an open format which can be easily parsed. SVG is a widely accepted vector graphics format and a number of authoring systems exist (e.g. Corel's Webdraw  ). Given these properties of SVG we regard it as a perfect fit for describing dynamic MHP applications.
SVG²MHP is our approach to solve the dilemma in today’s MHP application development. It enables rapid application development by taking SVG as input format to describe the visual components and the underlying program logic. From a content developer's point of view, SVG²MHP serves as a generator of an SVG Viewer for a given SVG. A designer creates the Xlets graphical elements and interface using any SVG enabled authoring software. A programmer later develops the execution logic utilizing SVG's scripting capabilities. Finally the SVG is transformed into an MHP compliant Java application that mirrors the SVG behavior when executed on the end users Set Top Box.
A conversion of the complete SVG language into MHP conformable Java terms turns out to be impossible due to several reasons. Some of them are imposed due to the hardware and software limitations of the MHP platform – others come up when considering the output device for MHP which still is in most cases an old-fashioned analogue TV screen.
The MHP specification only sets very few requirements to the hardware of Set Top Boxes. Hence the typical Set Top Box provides rather poor computing power and memory for running applications not to mention any hardware supported graphics acceleration. Therefore, supporting computationally expensive tasks and elements, such as complex filtering techniques, is certainly not feasible.
Another obstacle when translating SVG content into Java Code arises from the fact that the Multimedia Home Platform is based on the Java 1.1 API. In this release the Java Platform does not provide the feature-rich Java2D graphics engine available in later versions. Many elements natively supported by SVG can only be displayed using Java 1.1 by providing additional rendering code. Examples include the line-stroke and line-pattern attributes in SVG. Supporting these attributes would not only mean a tremendous effort to be done to enhance the rendering facilities of Java 1.1. Furthermore, it would mean to transmit additional rendering code together with the MHP application each and every time since it cannot be stored permanently. This, however, is not practicable - neither concerning the additional memory consumption on the already limited Set Top Box, nor in terms of the considerably increased band-width usage for MHP application broadcast.
An aspect one should also keep in mind is that the standard output media for MHP applications is a normal TV screen. It is not only limited in resolution (720 x 576 pixels for digital PAL) but the position of a viewer typically is also much further away compared to the user of a computer screen. Hence, those graphical aspects of SVG should be ignored which cannot reasonably be rendered on TV screens. This includes very thin lines and high resolution patterns as well as small serif fonts.
The SVG Tiny standard  – a true subset of SVG –already addresses hardware limitations. In fact we observed that SVG-T is a more appropriate choice than SVG with regard to the current Set Top Boxes. The graphical elements it specifies can be rendered despite hardware restrictions by omitting CPU-intensive calculations as well as attributes and elements which cannot reasonably be displayed on limited screens such as the ones TVs provide. Still it supports all the graphic primitives needed for user interfaces appropriate for TV applications. Consequently we concentrated our efforts on the ability to translate as much of the SVG-T specification as possible into MHP Java terms.
In the following chapter we will present selected aspects of the software architecture behind SVG²MHP and will give a more detailed view on how the translation process actually works. We will show to what extent the mentioned restrictions influenced the design and the implementation of SVG²MHP.
The basic architecture of SVG²MHP is similar to a pipeline consisting of different stages that have a well defined input and output.
While this architecture was determined by its purpose as a content transformation system, the real driving force behind many design decisions was the in many ways limited environment in which the generated Xlets have to run. Even though the MHP specification leaves some freedom to implementors in the capabilities (software and hardware side) their implementation can offer we had to design SVG²MHP so that any Xlet it creates can run on a minimally capable STB. Otherwise only parts of the desired audience could be reached. Also the STB available to our project for testing really only implemented the required minimum (and sometimes not even that!). This minimal environment proved in many ways to be very restricting. Some of our architecture and design decisions will therefore only be understandable if we elaborate about the given runtime environment for Xlets a bit more in detail.
Xlets and associated files and classes needed by them are delivered to an STB via the so called "data carousel" a data stream shared by all channels transmitted via DVB. The files in this carousel are transmitted cyclically and an Xlet or class loader can access them via normal file system semantics. Of course the waiting time for a file increases with the number of files and their size in the carousel. Add to this the transmission time of the actual file and it becomes clear why application size and complexity are severely restricted in the MHP environment. People used to zapping quickly through their TV channels will not accept long waiting times. Keeping the generated Xlets and Data files as small and lightweight as possible was therefore paramount for the success of SVG²MHP.
A typical STB runs with 8-16 MB of RAM and a CPU capable of 80-120 MIPS. All of these (sparse) resources are of course not available to the currently running Xlet since overhead for the operating system and application manager have to be accounted for. The MHP specification itself is surprisingly vague with respect to required processing power. It makes only the following minimum demands on the memory available to an Xlet : 
As one can see the Xlets (and associated class files) size and the available memory during runtime is limited to 256 KB. As with the transportation of the Xlets to the STB it becomes quite clear that keeping the Xlets final size and runtime memory consumption low was of highest importance to the project. It became also quite apparent that drawing to the TV screen is a very CPU intensive action for non hardware accelerated STBs. In this area rather than in the preliminary computation the low performance of the CPU made itself felt badly.
One of the biggest hindrances in the development of SVG²MHP was the necessity to use only the Java 1.1 API. Even though STBs are allowed by the MHP specification to offer newer Java APIs this is not usually done by STBs on the market. In our case the used STB didn't even allow the usage of newer container classes such as ArrayList etc. Besides the absence of many convenience methods an classes one has gotten used to after the introduction of Java 2 which was rather easily compensated the lack of the Java2D API for drawing was the biggest obstacle for SVG²MHP. Especially the following (non-)features of the Java 1.1 Graphics API proved to be very limiting:
Overall, the demands of rendering even a subset of SVG with this limited drawing API requires to emulate many features usually found in more modern drawing libraries.
Our STB was only able to display a depth of 3 bits per color channel and 4 different opacity values. Even though this had no real consequences on the architecture of SVG²MHP it definitely has to be taken into consideration when designing SVGs for display on the MHP. A bigger problem was the absolutely horrendous drawing speed we encountered (see appendix A). On our reference system, a single filled polygon with 4 edges takes more than 120ms for drawing with alpha blending. Painting an 200px * 100px image requires more than 120ms also. Under these circumstances animating an SVG becomes painfully unsmooth. Another performance limiting factor was the faulty implementation of the refresh mechanism in our STB, making a manual clearing of painted areas for every redraw necessary.
These restrictions in size and capabilities disallowed some of the more obvious designs for bringing SVG to the MHP. We could not just adapt an existing SVG viewer to the MHP because of the size and API restrictions. Batik's Squiggle SVG Browser , for example is just to heavyweight and relies heavily on the Java2D API not available to MHP. The TinyLine rendering engine could have been a viable rendering toolkit for our project because of its small footprint and ability to run under Java 1.1, but unfortunately the source is not available for adaption.
Since SVG²MHP is primarily a content transformation system, a pipeline where the source content (normal SVG files) is piped into one end and transformed in several stages into the desired output format was the obvious choice for the general architecture of SVG²MHP. To give the big picture we'll discuss this architecture first on a rather high abstraction level followed by a more detailed description of the different transformation stages.
The SVG²MHP pipeline is coordinated by a global instance. We provide two frontends for this coordinating class: a GUI frontend and a command line version that have main() entry methods and allow the user to specify the necessary parameters for the Xlet generation. This coordinating class ties together the different stages of the pipeline, meaning that no single stage needs information about where it gets its input from and where its output is passed to. This decoupling allows easily reusing the single stages independently and uncomplicated introduction of new stages to the pipeline. Meta information about the generation process is stored in a context class available to the different pipeline stages. It serves only a passive role as information store and was introduced to decouple the pipeline's logic from its state.
The minimum required parameters to start the pipeline are an SVG input file and a desired output directory for the output source code and the compiled Xlet. Other configuration parameters can be given via the GUI, the command line or a configuration file. Since parts of the pipeline need to manipulate (even rearrange) nodes of the document tree and our internal storage format on the Xlet is also a tree, a DOM based approach suggested itself. The parsing and generation of a DOM document tree from the input file is handled in the entry point of our pipeline and relies heavily on Apache Batik's SVGDOM implementation. 
In the second stage of the SVG²MHP pipeline several modifications to the SVGDOM tree occur that simplify later handling and manipulation. Among the modifications done to the SVGDOM are the following:
After the SVGDOM tree has been simplified, in the second stage it is converted to the MHPDOM format used for evaluation by the Xlet. This MHPDOM is a very simple tree based data structure that holds the minimal data necessary for rendering the nodes. The structure of the MHPDOM is equivalent to the structure of the SVGDOM apart from diverse attributes and elements that are not presentable on the STB. This equivalence allows a straightforward translation using a so called builder pattern. That means that every node has an equivalent builder that translates the SVG node into the accordant MhpNode. Besides the translation of the SVGDOM to the MHPDOM all declarative animations are transformed into a format suitable to run directly on the Xlet, in the third stage of the pipeline. In contrast to SVGDOM animations are not part of the MHPDOM structure but are held as a separate list so that the used time line concept can be realised efficiently.
In the final stage of the pipeline the code for the Xlet is created and compiled, containing only the needed capabilities to display the content of the MHPDOM tree. This MHPDOM tree is serialized and compressed to be loaded later again by the Xlet.
As said before, SVG supports more elements and attributes than could reasonably be displayed with the means of Java 1.1. For attributes such as the stroke width and the stroke pattern of lines for example, which are not natively supported in Java 1.1, we would have had to write a complete rasterizer. This solution would have been too slow to run reasonably on the Set Top Box. In order to be able to at least display these items under certain circumstances, we added a prerasterization step. During the simplification progress, subtrees of the SVG DOM can be replaced by raster image nodes. Since this is done with the help of Batik using Java2D, we can display all even complex elements using filters, patterns etc. that would otherwise not be displayable on an STB. The decision whether to prerasterize a node or not, is based on the employed rasterization strategy of which three currently exist:
The primary way to interact with the Xlet is the remote control. The MHP specification defines 20 keys that can be used to control an Xlet. A pointer interface as known from normal interactive SVG is not present. For defining key events an associated handler functions an own namespace was created, because the standard key event handling put the programmer in charge of checking which key is pressed. With the new namespace every key can be set as a separate attribute.
SVG²MHP comes along with a simple graphical user interface that allows to trigger the mentioned parameters necessary for content transformation. The following SVG document was transformed into a MHP compliant Xlet. This example is restricted to static content and is intended to illustrate some of the main aspects of content transformation as presented in the previous chapters.
Figure 4 shows the input SVG using the Inkscape Vector Graphics Editor .Figure 5 presents the SVG code.
<?xml version="1.0" encoding="UTF-8" standalone="no"?> <svg xmlns:xml="http://www.w3.org/XML/1998/namespace" xmlns:svg="http://www.w3.org/2000/svg" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" id="svg2" height="576px" width="720px"> <defs id="defs3"> <linearGradient id="orange_red" x1="0%" y1="0%" x2="100%" y2="0%"> <stop offset="0%" style="stop-color:rgb(255,0,0); stop-opacity: 0.7"/> <stop offset="100%" style="stop-color:rgb(255,255,0); stop-opacity: 0.7"/> </linearGradient> </defs> <image y="0" x="0" height="576" width="720" xlink:href="flower.jpg"/> <rect id="rect1" ry="30" rx="30" y="48" x="38" height="165" width="350" style="fill:#ffff88;stroke:black;fill-opacity:0.7"/> <text id="text11" y="75" x="59" style="font-size:20;font-family:MatrixScriptRegular;">This text uses a font which is</text> <text id="text12" y="100" x="59" style="font-size:20;font-family:MatrixScriptRegular;">unavailable on the Set Top Box.</text> <text id="rasterme_text21" y="143" x="59" style="font-size:28;font-family:MatrixScriptRegular;">This text object uses the</text> <text id="rasterme_text22" y="168" x="59" style="font-size:28;font-family:MatrixScriptRegular;">same font but this time</text> <text id="rasterme_text23" y="193" x="59" style="font-size:28;font-family:MatrixScriptRegular;">it is prerasterized.</text> <rect id="rasterme_rect2" ry="30" rx="30" y="450" x="30" height="60" width="640" style="fill:url(#orange_red);"/> <text id="text3" y="490" x="63" style="font-size:32;fill:#ffffff;">Currently on TV: My Garden</text> </svg>
Figure 5: SVG sample code
The SVG consists of a background image, two rectangles and three font objects. Both rectangles are filled using different values of opacity. Opacity is conserved throughout the transformation progress by using the alpha channel of the DVBColor object which is an MHP extension of the Java 1.1 Color object.
The rectangle in the lower part of the image uses a gradient filling. As said before, gradients are unavailable in Java 1.1 and a simple translation would therefore skip that rectangle. In order to preserve the gradient, we use the prerasterization stage here (namely the ID_RASTERIZATION stragtegy) and render the rectangle into a raster image which later is drawn on the Set Top Box.
The text objects in the SVG use different fonts which are not available on a Set Top Box. A typical MHP compliant receiver offers one single font to the developer: the Tiresias Screenfont  . This is a sans serif font which was designed to be easily readable on TV screens
Currently, SVG²MHP displays any font used by the SVG author with the Tiresias Screenfont, because it is the only font that is mandatory available on an STB. This can be seen when comparing the first text in the SVG with the resulting output in the Xlet. The second text however is again prerasterized by SVG²MHP. Hence, the appearance of that text in the Xlet equals the one in the SVG.
While the previous example is intended to show some properties of the conversion progress, the following two examples arose from a use-case study done in advance to this project. We developed several scenarios, where MHP would mean a true added value compared to today's TV consumption. In particular, we believe that the ability for the viewer to participate in the program is such a key feature.
The first example is a football ticker application – an Xlet that is broadcast simultaneously to important games of a certain league. It offers the viewer the ability to check the current scores and table rankings in that league. Furthermore, the viewer has the possibility to bet on the results of the current matches. Using the remote control, he can enter a possible outcome of a certain game and submit his guess back to the content provider that broadcasts the ticker. However, the latter option is not yet available on SVG²MHP generated Xlets since we currently have not integrated the return channel capabilities of MHP into our translation process.
The second example is a quiz game application - an Xlet is broadcast alongside a TV quiz show. TV viewers can answer the questions just as the official candidate and see how they would stack up against her. Registered users can even take part in a competition where the "couch candidate" with the best overall results during a TV show wins. This would of course have the nice side effect that viewers would not change channels during the show since then their scores could be reset. Great for making sure your advertisements are watched! In contrast to the former example the script provides not only interaction functionality but implements a complete independent processing logic. The question timer is triggered by a user interaction and acts like an animation that uses MHP specific time events to control the remaining time. At every time event the graphical element that represents the remaining time is updated by the script. The evaluation of the chosen answer is also realized within the script.
Currently, both examples remain case-studies since SVG²MHP does not make use of the return channel yet. However they show in simple means what can be realized using SVG²MHP and to what extent SVG²MHP might help to reduce MHP application development time. Implementing further features of both SVG and MHP will even improve SVG²MHP's usability.
In the current version of SVG²MHP we succeeded in translating most of the W3C SVG Tiny recommendation into corresponding Java terms.
SVG²MHP generates Java code that renders basic shapes:
Considerable effort was put on the implementation of transformations of simple and grouped basic shapes as well as motion and color animations. In spite of the lacking support by native Java 1.1 rendering routines, the mentioned graphics objects can be rotated, translated and scaled. This is reached by converting a shape into its polygonal representation. This approach is not applicable for raster images, hence images are restricted to translation and scaling – both inherent Java 1.1 image manipulation operations. Likewise, text objects can only be translated and scaled (by simply resizing the font objects) since the glyphs cannot be accessed directly to support rotation as well. However, the latter curtailing becomes of minor importance when considering that especially text objects should be placed and aligned carefully to keep being readable on low resolution output devices such as TV screens.
Shape rendering is delimited by drawing continuous 1pt lines. Java 1.1 does not offer more elaborate line drawing capabilities and, as said before, implementing a line renderer would simply be too costly in terms of bandwidth capabilities. Likewise, pattern support is missing in SVG²MHP.
By adding a prerasterization stage, we enable the user of SVG²MHP to render any SVG element into a static image. As this step is performed outside of the actual Xlet code, in this manner Java 1.1 does not limit the graphics capabilities anymore. Instead, the Batik rasterization engine is used throughout the transformation process which proves to be very powerful. However, it has to be said that the advantage of complete SVG support is at the expenses of object dynamics since raster images are transformable only within the mentioned limits.
The concept of user interaction in SVG strongly depends on a pointer device such as computer mouse. Since a TV is typically operated by means of a remote control, a new namespace is introduced for supporting remote control keys. In this way, certain actions within the SVG can be invoked by pressing the appropriate buttons.
Xlets executional logic can be added by writing parts of Java code. Thus, we re-enable the known division of labor in multimedia application development by passing the programming task back to programmers.
SVG²MHP proves to create stable Multimedia Home Platform compliant applications based on an SVG description of the visual components. It can help to significantly reduce the time to market of MHP applications and hence can serve as a catalyst for this quickly emerging technology.
Future improvements on SVG²MHP will focus on the extension of the supported SVG elements and attributes. We intend to completely support SVG-Tiny and even to exceed the standard in some areas suitable for our field of operation. A second very important step will be to make the return channel addressable within the SVG. As the return channel will typically be used for back transmission of certain data upon viewers request, it would probably be suitable to encapsulate the access to the appropriate Java routines within the Script interface. In this way, the back channel gets available to the developer of the execution logic of the Xlet and remains hidden to the graphic designer. In this regard the capturing of streamed events is an necessary extension to SVG documents that need to be triggered by an event that is broadcasted with the MHP video stream. Other improvements will include further code optimization in terms of size and speed of the transmitted Xlet code even though the opportunities for improvements in this area appear to be limited..
|graphics primitive||no alpha blending||alpha blending||no alpha blending, off screen||alpha blending, off screen|
|polygon, 4 edges, 200px * 100px||0,68ms||3,04ms||0,86ms||2,9ms|
|polygon, filled, 4 edges, 200px * 100px||7,92ms||124,39ms||3,9ms||107,2ms|
|rectangle, 200px * 100px||0,63ms||2,93ms||0,9ms||2,82ms|
|rectangle, filled, 200px * 100px||1,57ms||31,28ms||2,39ms||9,64ms|
|image, rectangle, 200px * 100px||113,8ms||114,4ms||-||-|
|image ,filled rectangle, 200px * 100px||113,3ms||138,6ms||-||-|
|circle, radius 100px||1,86ms||4,09ms||2,10ms||4,19ms|
|circle, filled, radius 100px||7,92ms||111,76ms||4,467ms||97,28ms|
|polygon, 201 edges, circular form, radius 100px||1,81ms||4,16ms||2,297ms||4,36ms|
|polygon, filled, 201 edges, circular form, radius 100px||8,89ms||101,46ms||6,27ms||87,26ms|
MHP 1.0 Specification p. 359f.
XHTML rendition made possible by SchemaSoft's Document Interpreter™ technology.