SVG Tiny cartoons on Java devices

Keywords: SVG Tiny , Mobile SVG , J2ME , Cartoon , SVGT Animation , SVGT Streaming

Andrew Girow
Tel Aviv


Andrew Girow specializes in creating and implementing high-performance J2ME and Java technologies as well as SVG and XML. In addition to Java and embedded software he develops server C/C++ applications under Windows and UNIX platforms.

Edik Mitgartz


Edik Mitgartz studied Classical Animation in "Bezalel" Academy of Art and Design, Jerusalem. He works as Animator ,Character Designer at Pitchi Poy Animation Studio, and is busy creating funny pictures for all kinds of media, from TV to Net to Mobile


The rise of the number of powerful J2ME mobile devices brings an opportunity to use pure J2ME Player for SVG Tiny cartoons. This paper focuses on the efficient design and encoding animated cartoons with SVG Tiny 1.1.

First, we discuss some technical basis behind vector graphics cartoons and various approaches to animations found in SVG Tiny 1.1. Next, we give the some practical methods how to design SVG Tiny 1.1 cartoons in effective way. Also we give some thoughts and considerations on the compression and streaming of SVG Tiny cartoons.

Table of Contents

1. Introduction
2. SVGT 1.1 Cartoons
3. Future development

1. Introduction

Many new powerful wireless devices are appearing on the market. These devices features 16 bit color display, more powerful CPU, the larger capacity of memory cards. But mobile video still lacks flexibility and presents poor performance. It is still "fuzzier and grainier" than what we see on television.

Movie film we see on television runs at 24 FPS (frames per second), which is sufficient to create this illusion of continuous movement. At rates below 24 FPS, most people can detect jerkiness. Modern mobile video decoders provide 7,5 -12 FPS on different mobile devices.

The reason that no jerkiness is seen at higher speeds is due to effect of "persistence of vision." From moment to moment, the human eye and brain actually store whatever you look at for a fraction of a second, and automatically "smooth out" minor jumps.

Cartoons are less eager for the frame per second rate. In drawn animation or cartoons, moving characters are often drawn "on twos" - one drawing for every two frames. Even though the rate of 12 FPS is as twice slow then 24 FPS, it is quite satisfactory. It saves the number of drawings needed and it is usually accepted because of the stylized nature of cartoons.

This stylized nature of cartoons and the "on twos" technology allow to achieve acceptable results and good user experience on mobile devices in comparison with mobile video.

A lot of propriety solutions and a lot of standards are developed for graphic animations - GIFS, SIS, MPEG-4 BIFS, Flash, SVG...

We will concentrate on the SVG Tiny (SVGT) standard because of it industry adoption:

  1. 3GPP selected Mobile SVG as the mandatory vector graphics media format in MMS and PSS [3GPP ] .
  2. The Java Community Process (JCP) have created a JSR-226 expert group lead by Nokia and Sun working on creating a standard SVG Tiny Java API for J2ME [JSR-226 ] .
  3. The recent MPEG Call for Proposals on Lightweight Application Scene Representation, commanding work on a binary format to represent scenes for use in a mobile environment, compatible with SVG Tiny [MPEG4 ] .

2. SVGT 1.1 Cartoons

SVG 1.1, Scalable Vector Graphics [SVG 1.1 ] , defines an XML language for describing 2D vector graphics. SVG allows for three types of graphic objects: vector graphic shapes (e.g. paths consisting of straight lines and curves, images and text. Graphical objects can be grouped, styled, transformed and composted into previously rendered objects. SVG drawings can be interactive and dynamic. Animations can be defined and triggered either declaratively or via scripting.

It has been established by industry demand, that some subset of SVG 1.1 suited to displaying vector graphics on small devices is required. In order to meet these demands the SVG Working Group has created SVG Tiny (SVGT) 1.1 profile specification [Mobile SVG 1.1 ] that addresses mobile devices.

Because of the low memory, low CPU power and limited display of mobile devices, SVGT 1.1 introduces some constraints on content, attribute types, properties, and user agent behavior. The details you can check at [Mobile SVG 1.1 ] .

We will concentrate on the animations features and abilities of SVGT 1.1 and later on SVGT 1.2 and how they fit for our goal to represent cartoons. But before, let us say a couple of words about time based and frame based animations.

An object which is time based animated will move from point A to point B in the same amount of time regardless of the frame. The slower the frame rate, the farther the object moves each frame in order to maintain the same speed.


Figure 1: Time based and frame based animations

On the other hand, if the animation is frame based the object will always take the same number of frames to get from point A to point B. The slower the frame rate, the longer it will take.

As frame rate slows, frame based animation slows down and time based gets "chunky". In other words, with a time-based animation, an animation lasts a certain amount of time; with frame based, the animation lasts a certain number of frames. Time based animation ensures that an animation will play at the same speed on all devices, but it may drop frames to make up for processor speed on less powerful devices. On the contrary, frame-based animation will always play every single frame of an animation, but the playback speed may slow down on less powerful devices.

SVGT animations are time based! The more formal definitions of SVGT animations can be found at the following specs [SVG 1.1 ] , [SMIL] .

For all our samples [Cartoons] we use the Beatware Mobile Designer [Beatware] as authoring tool and TinyLine SVGT Player [TinyLine] . See the references section for details.

SVGT animation defines a time-based operation on a target element [SVG 1.1 ] . It defines a mapping of time to values for the target attribute. Animations specify a 'begin', and a 'simple duration'. Each animation defines an animation function that produces a 'value' for the target 'attribute', for any time within the simple duration. The animator can specify how long or how many times an animation function should repeat.

Animation functions are continuous in time. They can be sampled at whatever frame rate is supported by the rendering system. The animation elements support syntax for discrete or interpolated values, SVG motion paths, keyframe based timing, paced or linear interpolations.

The following is a simple SVGT cartoon 'retro4.svg' that demonstrates complex motions and repeating behavior. The online example of this SVGT cartoon is avalable at ( (You need a Java enable browser to see it).


Figure 2: The retro4.svg cartoon

The presentation value reflects the effect of the animation upon the base value. The effect is the change to the value of the target attribute at any given time. When an animation completes, the effect of the animation is no longer applied, and the presentation value reverts to the base value by default. The animation effect can also be extended to freeze the last value for the remainder of the document duration.

The next SVGT cartoon 'happybirthdayp.svg' shows the usage of 'frozen' values.The online example of this SVGT cartoon is avalable at ( (You need a Java enable browser to see it).


Figure 3: The happybirthdayp.svg cartoon

Animations can be defined to either override or add to the base value of an attribute. The base value (or underlying value) may be the DOM value, or the result of other animations that also target the same attribute. Animations that add to the underlying value are described as additive animations. Animations that override the underlying value are referred to as non-additive animations.

The SVGT cartoon 'lambp.svg' shows the usage of additive and non-additive animations. The online example of this SVGT cartoon is avalable at ( (You need a Java enable browser to see it).


Figure 4: The lambp.svg cartoon

Till this point, all our cartoons were very basic. Now we want to create a 'real' SVGT cartoon that tells us some funny story.

SVGT cartoons, just like other forms of animation, usually begin life as a "storyboard". Storyboards are illustrations displayed in sequence for the purpose of crafting an animated film.


Figure 5: The storyboard of the surprise.svg cartoon

The storyboard provides a visual layout of events as they are to be seen. The images at the storyboard allow the animator to plan the flow of the story. For SVGT cartons the storyboard is the SVGT document. Images at the storyboard we name 'scenes'.

A scene represents logical cartoon unit at the storyboard from the animator point of view. A scene is started at some point in carton time and should be played for some duration time.

The first scene starts immediately and has the duration of 3 seconds.

<!-- Scene 1 Begin -->
<g id="Scene_1">
    <!-Scene Duration -->
       <set id="Play_Scene_1" attributeName="fill" to="#FFF" dur="3s"/>
<!-- Scene 1 End -->

Figure 6: SVG Code for the Scene 1

The second scene is not displayable at the beginning and is triggered to play when the first scene is finished. It also has the duration of 3 seconds.

<!-- Scene 2 Begin -->
<g id="Scene_2" display="none">
    <!-Scene Duration -->
    <set id="Play_Scene_2" attributeName="fill" to="#FFF"
       begin="Display_Scene_2.begin" dur="3s"/></g>
<!-- Scene 2 End -->

Figure 7: SVG Code for the Scene 2

The storyboard layout of events defines on which order scenes need to be played and provides the needed synchronization.

<!-- The storyboard layout of events -->
<set id="Hide_Scene_1" xlink:href="#Scene_1" attributeName="display"
   to="none" begin="Play_Scene_1.end" />
<set id="Display_Scene_2" xlink:href="#Scene_2" attributeName="display"
   to="inline" begin="Play_Scene_1.end" />
<set id="Hide_Scene_2" xlink:href="#Scene_2" attributeName="display"
   to="none" begin="Play_Scene_2.end" />
<set id="Display_Scene_3" xlink:href="#Scene_3" attributeName="display"
   to="inline" begin="Play_Scene_2.end" />

Figure 8: SVG Code for the storyboard layout of events

It normal language it is equivalent to the following instructions:

  1. Hide the first scene (Scene_1) when its duration is finished (Play_Scene_1.end). We do not need more the first screen, thus to avoid unnecessary processing we make it hidden.
  2. Show the second scene (Scene_2) by changing the 'display' attribute to 'inline' when the first scene (Scene_1) is finished (Play_Scene_1.end).
  3. Hide the second scene (Scene_2) when its duration is finished (Play_Scene_2.end). We don t need more the second screen, thus to avoid unnecessary processing we make it hidden.
  4. Show the third scene (Scene_3) by changing the 'display' attribute to 'inline' when the second scene (Scene_2) is finished (Play_Scene_2.end).

The SVGT cartoon 'Surprise' shows the usage of the 'scene' approach. The online example of this SVGT cartoon is avalable at ( (You need a Java enable browser to see it).

3. Future development

Using the 'scenes' approach exposed above and by adding the gzip compression it is possible to create SVGT 1.1 pretty impressive cartoons. However, the 'scenes' techniques have problems with real long cartoons.

The first problem is based on the fact that the whole carton is defined as an SVG document. It means that it must be loaded before we can start to play it. As a result of it, SVGT cartoons have an initial delay. In other words, the SVGT 1.1 lacks the progressive loading and streaming.

The second problem mirrors the fact that SVGT player stores the whole SVGT document in memory, despite of the fact that some parts of it are already not needed. Let us say, that the SVGT player started the scene number 4. All previous scenes are not needed. They should not occupy the mobile device memory!

The third problem is that special tricks introduced in order to define 'scene' duration.

The firth problem is the lack of soundtrack.

Here are comes SVGT 1.2 [SVGT12] to help. The SVG Tiny 1.2 mobile profile from one hand is a subset of SVG 1.2, defined to be suitable for small devices such as cellphones. From the other hand it is a natural continuation of the SVG Tiny 1.1. While the W3C SVG Mobile 1.1 defined two profiles (SVG Tiny and SVG Basic), the SVG Mobile 1.2 specification only defines one profile: SVG Tiny 1.2 [SVGT12] .

For SVG Tiny cartoons the most important changes to SVG Mobile 1.1, according to the SVGT 1.2 working draft are:

  1. Mobile DOM and scripting.
  2. Streaming.
  3. Multiple Pages.
  4. Progressive Rendering.
  5. Audio.

It is possible to use a scripting language and UDOM to perform animation of the object. However, scripting animations have several problems.

The scripting engine increases the memory footprint of the player. Second problem is that scripting animations by definition will be slower than the declarative animations. Third, the scripting engine by itself does not provide time based animation framework, so all needed calculations need to be implemented in the scripting language. Otherwise, the results are unpredictable. Our approach is to use declarative animations and use scripts only for events.

The 'scenes' approach could be mapped into Multiple Pages and Streaming definitions found in SVGT 1.2 but further studies and experiments need to be conduct.


[3GPP ]
3GPP , (
[JSR-226 ]
The Java Community Process (JCP) ( The JSR-226 public draft (
[MPEG4 ]
The MPEG Call for Proposals on Lightweight Application Scene Representation (
[SVG 1.1 ]
Scalable Vector Graphics (SVG) Version 1.1 Specification , Dean Jackson, editor, W3C, 15 February 2002. Available at (
[Mobile SVG 1.1 ]
Mobile SVG Profiles: SVG Tiny and SVG Basic, Tolga Capin (Nokia), editor, W3C, 14 January 2003. Available at (
SMIL Animation W3C Recommendation 04-September-2001. Available at (
Beatware Mobile Designer. Available at (
TinyLine SVGT Player. Available at (
SVG Tiny Gallery by Edik Mitgartz. Available at (
Mobile SVG Profiles: SVG Tiny and SVG Basic, Version 1.2. W3C Working Draft. June 29, 2004. Available at (

XHTML rendition created by gcapaper Web Publisher v2.0, © 2001-3 Schema Software Inc.