Lyfe Consulting

Optimisation's for embedded & limited devices.

Adobe Flash Lite.

Recently we've been working for two different clients under similar conditions; both projects utilised Adobe Flash Lite for innovative purposes on devices previously untouched by Flash.
The first project was for one of the UK's biggest enterprises to bring their video on demand service to one of the most innovative entertainment devices available, and the other was for an independent artist to showcase their work and map their upcoming shows. Utilising Adobe Flash Lite 3.1, we came across a number of different issues from performance to limitations.

Parsing asynchronously.

On embedded and limited devices, performing actions such as parsing can be detrimental to the user experience.
From a slight jutter to a noticeable pause in playback, the user experience will suffer if a single frame takes too long. Further more, any computation that takes too long will cause the Flash Player to throw a time-out error.
A time-out error is thrown when a single frame takes more than 15 seconds to render, but bare in mind that some embedded and limited devices may have a different (shorter) timeout limit.

One way to prevent, or at least mitigate any CPU-consuming computation from affecting the user experience, is to distribute parsing or the computation from one frame to multiple frames.
Take a look at the code below.

var lastIndex : Number = 0;
function onEnterFrame()
{
	var i : Number = lastIndex;
	var length : Number = data.length;
	
	for (; i < length; i++)
	{
		if (!canProcess())
			return;
		
		processData(i)
		// Store the current index
		lastIndex = i;
	}
	
	processComplete();
}

Using the onEnterFrame event handler as a template you can turn synchronous computations into asynchronous.
Instead of having any parsing/processing code within the for loop, we move it out into a helper function, processData. This helper function accesses the data Array and stores the result for the specific index, passed via the function argument.
In each iteration of the for loop we check the result of our canProcess function, this function checks the current time versus the elapsed time to make sure we haven't exceeded our preset acceptable time out.
If canProcess returns false then we need to exit the function and let the Flash Player runtime finish any other code execution and rendering. On the next frame we continue from where we left off as we saved our index as lastIndex.

MovieClips, Graphics & display.

The first obvious thing to take note of is that the device your targeting is likely to be 16 bit as where our devices. This means that gradients will often appear as banded solid steps rather than a smooth transition between two colours.
You could try dithering the bitmaps before use, but gradients and colour ideally should be a design consideration from the concept phase.

Animation is ideally an initial design consideration that affects the implementation of graphics (vector versus bitmap). Any graphic that needs to scale or rotate ideally needs to be a vector, and any graphic requiring a gradient should be a bitmap.

In most cases, such as controls and icons, your interface doesn't require fine detail. In these situations, avoid using curves as they are harder to render than straight lines. Straight lines work well for small icons where the user will not notice the lack of smooth curves.

Quick hints & tips.

Below are some more tips on optimising your Flash Lite content.

• If you don't need a reference/instance name, use a Graphic and not a MovieClip.
• Avoid bitmap rotation and scaling unless your device has hardware rendering.
• Use bitmaps for gradients rather than vectors.
• Do not use strokes, but use fills for vector outlines.
• Do not set a display object's _alpha to 0, instead, set _visible to false.
• Move display objects off stage to hide and gain a performance increase.

• Using Events is costly, try to use Broadcast.
• Casting is costly, avoid this if possible.
• Use Objects rather than Arrays. This is faster and improves memory usage.
• Reduce the number of classes used.
• Strict design patterns increase the number of classes, be pragmatic.
• Calling methods in another class is costly.
• Do not use third party XML parsers, instead, use the native runtime functions.
• Remove objects and variables as soon as possible.
• Do not use getters and setters, instead, use functions.
• If you use singletons, get the instance once and store it.