Posts Tagged actionscript
Lightspark progresses are never been so good. The last achievement was to correctly load, execute and partially render the YouTube player. As you may have seen YouTube has recently switched to Flash 10 and ActionScript 3.0 to serve some HD content, while keeping the old AS2 based player for lower quality videos. The old player is supported by Gnash but, until now, there where no open source alternatives to play newer, high definition content. As Lightspark AS3 engine matures, that gap is almost closed. Stay tuned, as I’m planning to release a new technology demo very soon.
UPDATE: Demo tarball released on sourceforge
Although there has been no official news about Lightspark for several months, i’ve been doing a great deal of work under the hood. As my bachelor thesis, I’ve mostly completed and throughly tested my LLVM based Actionscript 3 .0 JIT engine and, during the last days, I’ve been working on polishing a bit the Virtual Machine. I’m proudly announcing that, in some days, a new technical demo of Lightspark will be released, but this time we’re not talking about basic examples. Lightspark is now mature enough to run a simple application based on Flex.
Flex is a rich open source framework written in Actionscript and developed mainly by Adobe. Even if right now the test application features only a progress bar and a square, there is a lot of stuff being done by the framework under the hood.
If the framework works it means that the engine is now stable enough to move from a pre-alpha to an alpha status. The design is also now satisfying enough for me to allow other people to join the project and work on on subsystems without knowing the internal details of everything. As an added bonus preliminary support for the Windows platform will be included in the release.
The screenshot above is the result of the execution of my test application, for curious people the flash file is generated using the mxmlc compiler, from the following source file
<?xml version="1.0" encoding="utf-8"?>
<mx:VBox x="0" y="0" width="201" height="200" backgroundColor="0x0080C0" alpha="0.8"/>
I’m currently finishing some last cleanups and enhancements before releasing a second technical demo of the Lightspark Project. Much time is passed from the first demo, and the project is growing healty. This release aims at rendering the following movie, selected from adobe demo. The results may not be very impressive. But many things are going on under the hood.
The most interesting feature in this release are:
- GLSL based rendering of fill styles (eg. gradients)
- LLVM based ActionScript execution. Code is compiled just in time
- A few tricks are also played to decrease the stack traffic tipical of stack machines.
- First, although simple, framerate timing
- Framework to handle ActionScript asynchronous events. Currently only the enterFrame event works, as the input subsystem is not yet in place. But stay tuned, as I’ve some nice plan about that.
The code will be released in a couple of more days, or at least I hope so
One of the major challenges in the design of lightspark is the ActionScript execution engine. Most of the more recent flash content is almost completely build out of the ActionScript technology, which with version 3.0 matured enough to become a foundational block of the current, and probably future web. The same technology is going to become also widespread offline if the Adobe AIR platform succeedes as a cross platform application framework.
But what is ActionScript? Basically it is an almost ECMAscript complaiant language; the specification covers the language itself, a huge library of components and the bytecode format that is used to deliver code to the clients, usually as part of a SWF (flash) file.
The bytecode models a stack-machine as most of the arguments are passed on the stack and not as operands in the code. This operational description — although quite dense — requires a lot of stack traffic, even for simple computations. It should be noted that modern x86/amd64 processors employ specific stack tracing units to optimize out such traffic, but this is highly architecture dependent and not guaranteed.
LLVM (which stands fot Low-Level Virtual Machine) is on the other hand based on an Intermediate Language in SSA form. This means that each symbol can be assigned only one time. This form is extremely useful when doing optimization over the code. LLVM offers a nice interface for a bunch of feature, most notably sophisticated optimization of the code and Just-In-Time compilation to native assemply.
The challenge is: how to exploit llvm power to build a fast ActionScript engine.
The answer is, as usual, a matter of compromises. Quite a lot of common usage patterns of the stack-machine can be heavily optimized with limited work, for example most of the data pushed on the stack is going to be used right away! More details on this on the next issue...