We've got the basic core of OpenLaszlo compiling and running in SWF9. Thanks go to the good folks at g.ho.st (Global Hosted Operating System) for their support in this development. Here is a simple Laszlo app compiled to swf9 format and running in Flash 9. If you don't have a Flash 9 player installed, you won't be able to see it.
Simple SWF9 Demo
This is the source code for the app above:
<canvas width="800" height="600">
<view id="bar" x="200" y="200" >
</view><view id="foo" bgcolor="0xcccccc" x="-100" y="-100" height="200" width="200"
onclick="this.parent.animate('rotation', 90, 1000, true)" >
<text fontsize="18" fontstyle="italic">This is some text in a text view</text>
<view bgcolor="blue" width="40" height="40"
x="59" y="59"
onclick="this.animate('x', 10, 1000);
this.animate('y', 10, 1000)"/>
<view bgcolor="red" width="40" height="40"
x="101" y="59"
onclick="this.animate('x', 150, 1000);
this.animate('y', 10, 1000)"/>
<view bgcolor="green" width="40" height="40"
x="59" y="101"
onclick="this.animate('x', 10, 1000);
this.animate('y', 150, 1000)"/>
<view bgcolor="yellow" width="40" height="40"
x="101" y="101"
onclick="this.animate('x', 150, 1000);
this.animate('y', 150, 1000)"/>
</view>
</canvas>
A number of things have to be working to support this application:
- Kernel Sprite implementation
- LzEvent and LzDelegates
- LzNode is able to instantiate nodes with children, init methods, and setters
- LzView can create and manipulate kernel Sprites
- Idle events can be regsitered, so that animators can operate
- Kernel mouse events are forwarded to the LFC and dispatched to registered listeners
- Integration between the Laszlo compiler and the Flex mxmlc compiler
All of these are implemented, although the kernel sprite support needs to be fleshed out and optimized.
Things major that still need to be brought up in swf9 are
- constraints: we're not allowed to store the dependency functions on function in swf9, so we have to make the compiler put them someplace else
- XML data loading and parsing
- node replicators
- media playback
- drawview
- keyboard handling
- text and inputtext views
- browser/player communication
- debugger (although the Flash fdb debugger can be used for now)
- Selection manager, font manager
- embedded assets,fonts
We're got the development going on in a branch named "devildog", and in about a week or so should have things in place to allow people to start helping out if they want to get certain modules or features completed sooner, or fix bugs or optimize for the Flash 9 platform. There are a lot of new and improved APIs provided by the Flash 9 runtime; better media loading, data loading, and network APIs, as well as much more rational imaging and event model. We can probably take a lot of advantage of these by updating and optimzing the swf9 kernel and the runtime to use this where possible.
An quick overview of the approach to compiling to swf9 is outlined below.
The Flash 9 runtime contains a new virtual machine which has efficient support for JS2 style classes. If type declarations for variables and methods are provided, and use of some dynamic Javascript features is avoided, the application can run faster.
The Laszlo compiler emits AS3-compliant javascript class files, which are compiled by the Flex AS3 compiler, to produce an executable swf9 binary application file.
We currently compile the LFC library as a separate .swc AS3 library file, which is linked to the user application when the application is compiled.
Our plan is to have the LZX tag compiler phase emit real 'native' JS class declarations for user-defined classes (and all views, in fact). The LFC is already defined as JS2 style classes, using our own Class.lzs class system, designed by Tucker. We are converting these to be actual JS2 classes, which means no longer using our class initializer protocol. Stuff that is in now in class and instance initialize methods must be coded in some other manner.
Classes which are declared 'dynamic' in Flash 9 are slower to execute, since they must look up methods are variables by name at runtime, so we have been avoiding declaring LFC classes this way unless absolutely necessary, and would like to go back again and make another pass when things are all working to see which classes can be optimized to use only static lookups. We probably need to leave LzNode dynamic, given that we allow setAttribute at runtime on arbitrary properties, but there is a lot of room for optimization in the support classes in the system.
