Posts Tagged Flash
Having now sound synchronization fully working Lightspark has all the feature programmed for the 0.4.2 release! So no new big changes will be introduced, except for critical bugs reported.
But there are more big news! As I’ve revamped the plugin by switching from the old deprecated Xt interface to GTK, Lightspark has also gained Chrome/Chromium Plugin support and support for the new Out Of Process mode offered by newer versions of Firefox for improved stability and crash free experience.
Moreover, a contributor is currently porting Lightspark for the PowerPC platform and the work is currently in a very advanced stage. So PPC guys cheer up, Flash is coming!
I’m not sure those feature will be stable enough for the final 0.4.2 but will be surely included in the early 0.4.3 release cycle.
First of all, thanks a lot to all those brave enough to try out this project. I’m sorry about all the (frequent) crashes but, with the help of all the people who filed bugs on launchpad, the stability of Lightspark is improving very fast. Please keep testing and reporting any issues. The next big release, 0.4.0 codenamed “Aeolus”, is planned for the first week of June. The focus for this release is the stability of the platform and no major features are being implemented. The release is also going to include a brand new logo! The call for logos of the previous post generated a lot of very nice works, and it was very hard to choose between them. In the end I managed to keep only two of them, and now it’s your turn! Vote for the one you prefer.
Beside aesthetic things I’m also trying to define a bit the roadmap of the project. If the next release is only focused on stability, for the following one (0.5.0, codenamed “Bacchus”) I’m planning working Youtube support which was lost after one of the updates of the video player.
I’ve also received a lot questions and interest about porting Lightspark to other OSs and architectures. The code is build using standard technologies, such as pthreads and STL and should be quite portable, but some critical code paths has been written in assembly to guarantee atomicity or improve performance. I’ve very little experience with anything beside x86/x86-64, so I prefer not to port such critical code. However I will gladly accept any contributions for other platforms, such as PPC and ARM. The good news is that a contributor managed to compile lightspark on FreeBSD/x86 with minimal changes to the build system and a windows port is also planned. Moreover, beside the Ubuntu PPA I’m maintaining, packages are being created for Arch Linux and Debian, thanks a lot to the community.
More than a year has passed since the beginning of the Lightspark project. It was a long time indeed, but not wasted. I’m extremely pleased with the current level of support and the robustness of the system. You may be wondering “What the heck is lightspark?”, so let me introduce it.
Lightspark is an open source Adobe Flash implementation, designed from the ground up to be efficient on current and (hopefully) future hardware.
The long term objective of this project is not only to deliver a free as in freedom flash player, but also to give to the Flash technology the dignity of a real open standard. I really believe Flash is a powerful technology, it’s main weakness being it’s closedness. Lightspark has been entirely designed after Adobe released the SWF file format documentation, so no reverse engineering has been done.
- OpenGL based rendering allows for fast rendering of geometries and video frames. Moreover, although those are not yet supported, blur and other effects can be implemented using shaders for maximum efficency. Using OpenGL textures to display video frames is a bit less efficent than using XVideo, but make it possible to support any overlaying/transformation effect that flash provides.
- Mostly complete support for the newer version of the flash scripting language: ActionScript 3.0, introduced with Flash 9. Both an interpreter and a JIT engine based on LLVM are provided. The previous versions of the language (supported by Gnash, which does not support 3.0) run on a completely different, and quite weird, virtual machine. Currently Ligthspark does not support the older engine, but most sites (e.g, YouTube) are migrating to the newer engine, so we will be fine just with 3.0
- Beside the Virtual Machine Flash provides a huge runtime libraries that ranges from Video Rendering services to XML parsing. Implementation of the runtime is of course far from complete, but the architecture of the VM makes it possible to easily implement the various objects in plain C++. Moreover, an arbitrary degree of mixing between VM generated and C++ code is possible. This means that functions can be called from whatever context without worrying about their origin.
- A mozilla compatible plugin is provided, I’ve spent a lot of time trying to make the code robust to unexpected conditions and it should fail gracefully and display a gentle message. But, as plugins runs inside the browser process, there a not-so-slight possibility of crashes. Please report any crashes using the bug reporting system of launchpad
- As an added bonus, during development I’ve also added a couple of interesting performance profiling/debugging features which are not provided by the original Adobe player. Keyboard shortcut can be used to enable a profiling overlay, and a primitive inspector of the objects on screen
Just a brief news. It’s been a long way, and today I’m very proud to announce video streaming support for Lightspark, the efficient open source flash player. Moreover, performance looks very promising, I’m not going to publish any results right now as I’d like to do some testing before. Anyway, Lightspark seems to be outperforming Adobe’s player by a good extent, at least on linux.
In the next post I’ll talk a bit about some performance tricks that made it possible to reach such result.
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"/>
Developing and optimizing Lightspark, the modern Flash player, I’m greatly expanding my knowledge and understanding of GPU internals. In the last few days I’ve managed to find out a couple of nice tricks that boosted up performance and, as nice side effects, saved CPU time and added features
First of all, I’d like to introduce a bit of the Lightspark graphics architecture
The project is designed from the ground up to make use of the features offered by modern graphics hardware. Namely 3D acceleration and programmable shaders. The Flash file format encodes the geometries to be drawn as set of edges. This representation is quite different from the one understood by GPUs. So the geometries are first triangulated (reduced to a set of triangles). This operation is done on the CPU and is quite computationally intensive, but the results are cached, so overall this does not hit performance.
Moreover Flash offer several different fill styles that should be applied on geometry, for example solid color and various kind of gradients. Lightspark handles all those possibilities using a single fragment shader, a little piece of code that is invoked on every pixel to compute the desired color. Of course the shader has to know about the current fill style. This information along with several other parameters could be passed with different methods. More on this on the next issue.
There is one peculiar thing about the shader though, let’s look at a simple pseudo code:
Selector is a binary array, the only allowed values are zero or one. Moreover only one value is one. This means that the current fragment (pixel) color is computed for every possible fill style and only afterward the correct result is selected. This may look like a waste of computing power, but it is actually more efficient than something like this:
if(selector) gl_FragColor=solid_color(); else if(selector) gl_FragColot=linear_gradient(); ...
This counter intuitive fact comes from the nature of the graphics hardware. GPUs are very different from CPUs and are capable of cruching tons of vectorial operations blindingly fast. But they totally fall down on their knees when encountering branches in the code. This is actually quite common on deeply pipelined architecture which misses complex branch prediction circuitry, not only GPUs but also number crunching devices and multimedia monsters such as IBM Cell. Keep this in mind when working on such platforms.
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...
When some months ago Adobe released the complete SWF file format specification I though that it would be nice to develop a well designed open source flash player. Now I’ve been working for some time on this idea and I’ve recently relased the code on SourceForge.
The project objectives are quite ambitious, as the flash specification are really complex. The project is designed to take advance of the feautures present on modern hadrware, so it not supposed to run on older machines. All the graphic rendering is done using OpenGL and in the future programmable shaders will be used to offload even more calculations on the GPU. Extensive multithreading is employed to make use of multicore and hyper-threading processors. I’ll write a more detailed post about some tricky and interesting part of the project soon.