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.