LiveCode 10 – Sneak Peek

Brand New Web Deployment Experience

Web deployment is getting a major overhaul in LiveCode 10. A raft of changes will make it into a first class citizen, suitable for a much broader range of deployments.

The new version is based on Web Assembly (WASM). That enables a lot. In the first developer preview you can expect:

• Approximately 4x faster out of the box
• About 33% less initial memory required
• Enables the use of “wait” in your code

Let’s look a little closer at what each of these mean.

4x Faster

Your end users will experience a significantly snappier Web app. Almost every aspect of the app will run faster, from loading to script execution to the UI.

For the curious, we have some benchmarks:

33% less Initial Memory

The initial build brings a substantial memory saving already. We’ll aim to continue to reduce the memory footprint in future builds. Less memory also means your end users will not need to wait as long for a first load of your Web app. Always a good thing. People don’t like waiting… except in code, bringing us to our next item:

Wait Enabled

This is a big deal in itself.

You may think of “wait” as just one command in your code, but that isn’t the case. In reality, the LiveCode engine uses “wait” internally for a number of operations. Because “wait” will now work, you can use blocking operations in your Web app such as get, post and delete url. A significant set of operations and features can now be implemented for your app without awkward workarounds.

New Web Widgets

We’re working on more native Web widgets. The first build will have a new Map Widget, allowing you to implement maps in your app without awkward workarounds. 

Our new Web experience is a work in progress, so please check back here for more in future.

M1 Architecture Support

LiveCode currently runs on Rosetta 2 on the new M1 Macs. This gives performance pretty similar to what you get on the Intel Macs. In LiveCode 10 we will be adding native support for the M1 architecture, which will bring both a performance boost and future proofing. We expect the native M1 LiveCode to run faster with a smaller footprint. Standalones will be built as universal binaries, ensuring they run everywhere in the future.

Windows Player Media Foundation

The current player on Windows uses DirectShow – which only natively supports the WMV file format. Newer video formats (such as MP4) require third-party codecs to be installed. The move to Media Foundation will mean these are natively supported. MediaFoundation libraries support all the modern codecs such as mp4 natively – so mp4s will play in player objects without any thirdparty components needing to be installed in the OS.

Additionally, mirrored video playback will work correctly as well as non-standard playback rates.

This brings parity between Windows, macOS, Android and iOS video playback features in terms of supported video formats.

Windows Camera Media Foundation

As for the Windows Player, the Camera support on Windows will move to Media Foundation, with similar benefits. Newer video formats like MP4 will be supported out of the box.

Improved AcceleratedRendering on Mobile

The accelerated rendering implementation on iOS and Android will be updated to use OpenGL3ES internally, bringing improvements to attainable framerate (i.e. faster / smoother graphics in that mode).

Mobile Widgets

We are pleased to say we have now acquired full rights to the Mobile Widgets previously owned and maintained by LiveCode Factory. We will be integrating these widgets into LiveCode 10, providing a range of out of the box native objects for mobile platforms, with bug fixes and enhancements to the existing widgets. Initially these will include:

• activity indicator
• switch
• date picker
• time picker
• progress
• slider
• label
• search bar

New Syntax in 10

We’ve added some exciting new syntax for LiveCode 10, bringing you even more power and flexibility within the LiveCode language.

Array Literals

This will allow writing arrays in JSON-like notation direct in LiveCode script:

   put { "a": "b", "c": "d" } into tVar1

Instead of:

   put "b" into tVar1["a"]
   put "d" into tVar1["c"]

Other examples:

put [ 1, 2, 3 ] into tVar2
put [ { "a": "b" }, tVar2 ] into tVar3

The benefit of this is that you can easily express structured data direct in script without using lots of put statements.

Syntax for such (constant!) literals is the same as Python and JSON, allowing easy copy-paste interoperability between the languages.

Constant Expressions

Currently constants defined using constant declarations are limited to single tokens. e.g.

constant kFoo = "foo"

So you cannot build constants from more complex expressions. Constant expressions will lift this restriction so you will be able to do things like:

constant kFoo = ("foo" & "bar" && (1 + 2))

Static Switch Optimization

Currently switch statements check each case in turn until one is found which matches. e.g.

switch tVar
	case "foo"
		break
	case "bar"
		break
	case "baz"
		break
	default
		answer "none found"
	end switch

If tVar is “baz” – then the engine will do three comparisons to determine that is the case.

Essentially this means that the time taken to execute a switch statement increases as the number of cases grows – making very large switch statements slower.

The static switch optimization recognises cases where all the cases are constant expressions, and optimizes the lookup so only a single comparison (array lookup) is needed.

This means for those kinds of switches, there can be arbitrarily many cases without impacting performance.

Constant Folding

Currently all expressions are evaluated at runtime regardless of whether they change or not. For example:

put (1 + 2) / 3 into tVar

Here every time that statement is executed, the engine will evaluate 1 + 2, and then divide the result (3) by 2 even though the value of (1+2)/2 can be known at compile time.

Constant folding means that the engine is able to pre-evaluate what it finds to be constant expressions while compiling, meaning work is not repeatedly done that is not needed.

A really good use for this is to allow string constants which contain newlines without impacting performance:

put format("Hello\nWorld\n") into tVar

Here the format function use will be seen as a constant expression, and evaluated as the wanted string with the return characters in place – without it having to be repeatedly recomputed when executed.

Tail Expressions

The ability to pass arguments to a handler call using an array. e.g.

put 1 into tArgs[1]
put 2 into tArgs[2]
put MyFunc(... tArgs) into tResult

This will call MyFunc as

MyFunc(tArgs[1]. tArgs[2])

All This Coming Soon

We are looking forward to bringing you all this in the LiveCode 10 release cycle. You can expect to see the first dp (developer preview) of LiveCode 10 within the next couple of weeks. We can’t wait! Stay tuned for the first dp announcement and more posts about LiveCode releases in the coming days.