Office of Digital Humanities

Miscellaneous Optimizations
For LiveCode Mobile Apps

Here are a few tips for making your LiveCode-based apps run more smoothly.

LiveCode v. 5 featured a reworked graphics rendering engine designed to take advantage of modern graphics technologies and generally make screen redraws faster. Taking advantage of these changes require small changes in how one scripts their stacks.

Lock Screen and Visual Effects

This format should be used to make sure visual transition effects run as smoothly as possible.

  lock screen for visual effect
    -- change goes here; e.g., hide/show, go card, etc.
  unlock screen with visual effect whatever

The acceleratedRendering Property

The acceleratedRendering property is a shorthand way of setting several LiveCode graphics rendering properties to values that are optimal for the current platform your stack is running on. (See the LiveCode Dictionary entry for more details.)

Using this property is straightforward. In a preOpenCard or preOpenStack handler simply include this statement:

  set the acceleratedRendering of this stack to true

Note that in some cases the acceleratedRendering property is not appropriate; for instance on cards that have no changing or movable objects. Long-time LiveCode developer Jacqueline Landman Gay posted this to the Use-LiveCode mailing list:

"If you move to a card that has no dynamic objects anywhere, set the acceleratedRendering to false. Trying to dynamically render a non-dynamic card is very slow. When you go back to a card with draggable objects, set it back to true. My app only has one dynamic card, so I just turn off rendering on closecard and back on again in preOpenCard."

The layerMode Property of Objects

In conjunction with LiveCode's new graphics rendering features this property was added in LiveCode v. 5. The Dictionary describes its purpose:

"Use the layerMode property to specify if an object is static or dynamic. The LiveCode engine uses this to optimize rendering performance by caching objects that are moving or changing regularly."

Here is the syntax:

  set the layerMode of control to value

After some testing, Jacque Gay reported this to the Use-LiveCode mail list:

"The docs say you should set the layermode of the highest possible (topmost) object. So if you're dragging a group, set the layermode of the whole group and not any of the objects in it. If you are dragging individual objects, then each one gets a dynamic layermode. The goal is to keep the redraws as few as possible; redrawing the group as a whole is faster than individually redrawing every object inside it."

And LiveCode developer Mats Astrom reported:

"...Since i started setting acceleratedrendering of the stack to true and the layerMode of the scroller group to "scrolling" (has to be set in a script) everything works as expected."

Using the Device Refresh Rate

This command, added in LiveCode v. 5, lets you choose to use the iPhone screen refresh rate rather than that of the LiveCode engine. According to the Dictionary:

iphoneSetRedrawInterval - Synchronizes LiveCode redraws with the device's refresh rate.

When to Use

This feature should be used for applications that cause the screen to be redrawn often or where redraws are being called by various application elements. For example, scrollers, dragging and the move command all independently request redraws causing a build up which can lead to 'judders' and other unwanted drawing issues.

Improving Image Performance by Caching

Starting with LiveCode v. 6, all images are cached, meaning they don't have to be decompressed each time they are displayed, resulting in better performance in apps with lots of images. This has implications on how best to display multiple copies of images in a stack. Previously it was recommended to use a button icon to display images. With this new caching capability it is possible to efficiently reference an external image in multiple image objects. From Mark Waddingham, RunRev CIO:

"The image cache is keyed on absolute filename of image thus it is now highly efficient to use image objects referencing the same filename, rather than buttons referencing icons. In particular, there will only ever be one decompressed set of image data for a given (absolute) filename in the cache at any one time." (See Rev-up article describing this change.)

  prepare image <name> [ of ... ]
  prepare image file <filename>