Tips

Reducing image use

The biggest bloat to the JAR size will be images and these should be avoided where possible or made as small as possible.

Repeating an image

There is no overhead for repeating an image in different frames of a movie since the image will only be stored once in the JAR file. An image tiling function is provided and this can be useful to create rich backgrounds with small tileable images just like in a normal webpage.

Sound formats to avoid

When using sounds MIDI is the best format for music and sampled formats like WAV should be avoided if at all possible because of the huge size compared with the shortness of the clip. If the phone doesn't support MIDI then ringtone formats such as OTT may be the best alternative.

Reduce the number of layers

Using more layers doesn't increase the size of the movie very much but it does increase the memory needed at runtime and slightly impact performance. Less layers is better. If a movie has a very large number of layers consider splitting the movie into two or more movies which are chained together.

In general it's worth putting as much as possible onto a single layer. Anything that will be shown at the same time and will move together should be put into one layer.

Hiding layers

If a visible layer is no longer needed in a movie then it is better to 'hide' the layer even if it's graphics have been moved off screen. This ensures the movie player doesn't try to paint the graphics when it doesn't need to.

Avoid excessive moves on slower processors

It's tempting to spice up animations with objects moving around in all directions but moves consume processor resources and on slower cell phones this can be a problem. One way to address the problem of a slower processor is to increase the 'Resolution' of the movie to a higher amount such as 150 MSecs. With a higher resolution the player will make larger jumps to accomplish the move. The alternative is to a move event for a layer is to create a move explicity on the timeline with a series of show events one after the other.

Use the standard MIDP midlet player if appropriate

Many phones will run the standard MIDP midlet JAR file and this is recommended for the smallest player size but only where specific phone features such as sound are not required during playing. The player size is smaller precisely because many phone specific enhancements are not implemented. If a phone specific enhancement is requested in the movie but not implemented in the player the player will still run though without the enhancement showing up.

Try to avoid looping CSX files on the server

To make the player small, movies that loop on themselves do so by reloading the movie from scratch. A repeating CSX file located on a server will therefore load itself from the server every time it loops. This is both slow and inefficient and the way to avoid it is to keep any looping parts of the movie inside the original JAR file so the reloading avoids any network transfers taking place.