OpenLaszlo Performance Tip: Pause Invisible Animations

Over the years, I’ve looked at a number of OpenLaszlo applications that have needed performance tuning. Some performance-tuning involves significant re-writing of applications. However, I’ve also seen a number of common patterns that could be addressed by some developer guidelines on things to do, and things to avoid. So I’ve decided to publish this series of tips on OpenLaszlo performance tuning.

This first tip, “Pause Invisible Animations” pertains to runtime performance. I’ll discuss the various areas of performance in a later post, but for now, I figured I’d start this series with a tip that most OpenLaszlo developers can implement right away.

In OpenLaszlo, developers frequently use animated SWF resources in your applications (e.g. for loading indicators). These SWFs may take the form of a spinning wheel, an hourglass etc. When it’s no longer needed, you might disable the loading indicator by making it invisible. If you make an animated SWF invisible, but don’t stop it, then it will continue to consume client CPU while the animation is in progress. One animated SWF won’t slow an application significantly, but a number of animations that are running could account for a few percentage-points of CPU.

Fixing the problem is easy: just call stop() on the relevant views before making them invisible. There’s no reason not to stop invisible animations.

Determining whether you have animations you can’t see is also relatively easy. First, you’ll need the Debugger Version of the Flash Player. This is a browser-plugin, just like the standard Flash Player, and once installed, it will replace the existing player. The debugger player includes an option in the right-click menu to “Show Redraw Regions”. This feature visually identifies which parts of your application are actively getting redrawn (thereby consuming CPU), by highlighting them in red.

I tested this on the current version of Laszlo Webtop, (which you can try on www.gowebtop.com) and noticed a few animations that could easily be removed:

Stopping these animations will reduce CPU load while the application is being used, allowing important actions to execute a little faster.

scriptlimits Attribute

OpenLaszlo 4.0.10 (released yesterday) includes the new scriptlimits attribute of canvas, which allows developers override Flash’s default script timeout and recursion settings.Â I wrote about how to change these limits manually a while ago, and this has now been turned into a feature of OpenLaszlo.

The syntax is as follows:

You should avoid setting the limits high to avoid the scrip-running-slowly error on poorly-performing applications. Instead reduce the limits when testing your application, to surface performance problems sooner on faster machines. Fix the root causes of poor performance, then increase the limits for deployment.

Latest OpenLaszlo Reference

If you’re not already using it, I’d highly recommend you start using the nightly builds of the OpenLaszlo Reference. You can either download a nightly build of OpenLaszlo that contains it, or use the hosted live copy. Unless you really need to read it offline, use the hosted version.

This trunk version of the reference looks similar to the old OpenLaszlo 3.x reference, but the doc generation tools have been rewritten from scratch, and the standards have been revised. It’s more accurate, more events are listed, the appearance is cleaner and the categories have been simplified. Here’s how the new attribute categories work:

initialize-only: You can only set this attribute once, when initializing the object. It doesn’t matter if you use a tag or script to initialize the object. e.g. name, id.
read-write: This is an attribute that you can change at run-time (via a setter method or the generic setAttribute() setter method, or a constraint). e.g. x, width.
readonly: You can not set this attribute at init time (either in a tag or in script), but you can read it using JavaScript (using dot-syntax), or inside a constraint. e.g. framesloadratio, totalframes.

Note that if you download OL 4.0.9.1 (the current stable version), you won’t get the latest reference; instead you’ll get the old 4.0 one, that’s worse than the 3.x version.