Posts Tagged Flash

Lightspark 0.4.2 RC3... almost ready

Hav­ing now sound syn­chro­niza­tion fully work­ing Lightspark has all the fea­ture pro­grammed for the 0.4.2 release! So no new big changes will be intro­duced, except for crit­i­cal bugs reported.

But there are more big news! As I’ve revamped the plu­gin by switch­ing from the old dep­re­cated Xt inter­face to GTK, Lightspark has also gained Chrome/Chromium Plu­gin sup­port and sup­port for the new Out Of Process mode offered by newer ver­sions of Fire­fox for improved sta­bil­ity and crash free experience.

More­over, a con­trib­u­tor is cur­rently port­ing Lightspark for the Pow­erPC plat­form and the work is cur­rently in a very advanced stage. So PPC guys cheer up, Flash is coming!

I’m not sure those fea­ture will be sta­ble enough for the final 0.4.2 but will be surely included in the early 0.4.3 release cycle.

, , , ,


Lightspark News: Progress on stability, Codenames and Logo Poll

One of these will be the offi­cial logo of Lightspark

First of all, thanks a lot to all those brave enough to try out this project. I’m sorry about all the (fre­quent) crashes but, with the help of all the peo­ple who filed bugs on launch­pad, the sta­bil­ity of Lightspark is improv­ing very fast. Please keep test­ing and report­ing any issues. The next big release, 0.4.0 code­named “Aeo­lus”, is planned for the first week of June. The focus for this release is the sta­bil­ity of the plat­form and no major fea­tures are being imple­mented. The release is also going to include a brand new logo! The call for logos of the pre­vi­ous post gen­er­ated a lot of very nice works, and it was very hard to choose between them. In the end I man­aged to keep only two of them, and now it’s your turn! Vote for the one you prefer.

Beside aes­thetic things I’m also try­ing to define a bit the roadmap of the project. If the next release is only focused on sta­bil­ity, for the fol­low­ing one (0.5.0, code­named “Bac­chus”) I’m plan­ning work­ing Youtube sup­port which was lost after one of the updates of the video player.

I’ve also received a lot ques­tions and inter­est about port­ing Lightspark to other OSs and archi­tec­tures. The code is build using stan­dard tech­nolo­gies, such as pthreads and STL and should be quite portable, but some crit­i­cal code paths has been writ­ten in assem­bly to guar­an­tee atom­ic­ity or improve per­for­mance. I’ve very lit­tle expe­ri­ence with any­thing beside x86/x86-64, so I pre­fer not to port such crit­i­cal code. How­ever I will gladly accept any con­tri­bu­tions for other plat­forms, such as PPC and ARM. The good news is that a con­trib­u­tor man­aged to com­pile lightspark on FreeBSD/x86 with min­i­mal changes to the build sys­tem and a win­dows port is also planned. More­over, beside the Ubuntu PPA I’m main­tain­ing, pack­ages are being cre­ated for Arch Linux and Debian, thanks a lot to the community.

, , ,

No Comments

Lightspark, an innovative FLOSS Flash player, reaches Beta Status

More than a year has passed since the begin­ning of the Lightspark project. It was a long time indeed, but not wasted. I’m extremely pleased with the cur­rent level of sup­port and the robust­ness of the sys­tem. You may be won­der­ing “What the heck is lightspark?”, so let me intro­duce it.

Lightspark is an open source Adobe Flash imple­men­ta­tion, designed from the ground up to be effi­cient on cur­rent and (hope­fully) future hardware.

The long term objec­tive of this project is not only to deliver a free as in free­dom flash player, but also to give to the Flash tech­nol­ogy the dig­nity of a real open stan­dard. I really believe Flash is a pow­er­ful tech­nol­ogy, it’s main weak­ness being it’s closed­ness. Lightspark has been entirely designed after Adobe released the SWF file for­mat doc­u­men­ta­tion, so no reverse engi­neer­ing has been done.


I’ll try to review and sum­ma­rize what as been done so far, and what is planned for the future.

Lightspark show­ing video. Pro­fil­ing graphs can be over­layed on the movie.

  • OpenGL based ren­der­ing allows for fast ren­der­ing of geome­tries and video frames. More­over, although those are not yet sup­ported, blur and other effects can be imple­mented using shaders for max­i­mum eff­i­cency. Using OpenGL tex­tures to dis­play video frames is a bit less eff­i­cent than using XVideo, but make it pos­si­ble to sup­port any overlaying/transformation effect that flash provides.
  • Mostly com­plete sup­port for the newer ver­sion of the flash script­ing lan­guage: Action­Script 3.0, intro­duced with Flash 9. Both an inter­preter and a JIT engine based on LLVM are pro­vided. The pre­vi­ous ver­sions of the lan­guage (sup­ported by Gnash, which does not sup­port 3.0) run on a com­pletely dif­fer­ent, and quite weird, vir­tual machine. Cur­rently Ligth­spark does not sup­port the older engine, but most sites (e.g, YouTube) are migrat­ing to the newer engine, so we will be fine just with 3.0
  • Beside the Vir­tual Machine Flash pro­vides a huge run­time libraries that ranges from Video Ren­der­ing ser­vices to XML pars­ing. Imple­men­ta­tion of the run­time is of course far from com­plete, but the archi­tec­ture of the VM makes it pos­si­ble to eas­ily imple­ment the var­i­ous objects in plain C++. More­over, an arbi­trary degree of mix­ing between VM gen­er­ated and C++ code is pos­si­ble. This means that func­tions can be called from what­ever con­text with­out wor­ry­ing about their origin.
  • A mozilla com­pat­i­ble plu­gin is pro­vided, I’ve spent a lot of time try­ing to make the code robust to unex­pected con­di­tions and it should fail grace­fully and dis­play a gen­tle mes­sage. But, as plu­g­ins runs inside the browser process, there a not-so-slight pos­si­bil­ity of crashes. Please report any crashes using the bug report­ing sys­tem of launchpad
  • As an added bonus, dur­ing devel­op­ment I’ve also added a cou­ple of inter­est­ing per­for­mance profiling/debugging fea­tures which are not pro­vided by the orig­i­nal Adobe player. Key­board short­cut can be used to enable a pro­fil­ing over­lay, and a prim­i­tive inspec­tor of the objects on screen
There­fore I declare lightspark to be in beta sta­tus! Now the most impor­tant thing that is still miss­ing is a nice Logo for the project. I’m very bad at art, so any con­tri­bu­tion is very wel­come. And of course the whole project, in a pure open phy­los­o­phy, is open to con­tri­bu­tion! To have a quick glance at the cur­rent sta­tus it is pos­si­ble to get lightspark pack­aged from our PPA on launch­pad.
Lightspark should fail in a clean way on unsupported Flash movies

Lightspark should fail in a clean way on unsup­ported Flash movies

, , ,


Lightspark gets video streaming

Just a brief news. It’s been a long way, and today I’m very proud to announce video stream­ing sup­port for Lightspark, the effi­cient open source flash player. More­over, per­for­mance looks very promis­ing, I’m not going to pub­lish any results right now as I’d like to do some test­ing before. Any­way, Lightspark seems to be out­per­form­ing Adobe’s player by a good extent, at least on linux.

In the next post I’ll talk a bit about some per­for­mance tricks that made it pos­si­ble to reach such result.

, , , ,

1 Comment

Lightspark’s news

Lightspark pro­gresses are never been so good. The last achieve­ment was to cor­rectly load, exe­cute and par­tially ren­der the YouTube player. As you may have seen YouTube has recently switched to Flash 10 and Action­Script 3.0 to serve some HD con­tent, while keep­ing the old AS2 based player for lower qual­ity videos. The old player is sup­ported by Gnash but, until now, there where no open source alter­na­tives to play newer, high def­i­n­i­tion con­tent. As Lightspark AS3 engine matures, that gap is almost closed. Stay tuned, as I’m plan­ning to release a new tech­nol­ogy demo very soon.

UPDATE: Demo tar­ball released on source­forge

, ,

No Comments

Extreme FLEXibility

Although there has been no offi­cial news about Lightspark for sev­eral months, i’ve been doing a great deal of work under the hood. As my bach­e­lor the­sis, I’ve mostly com­pleted and throughly tested my LLVM based Action­script 3 .0 JIT engine and, dur­ing the last days, I’ve been work­ing on pol­ish­ing a bit the Vir­tual Machine. I’m proudly announc­ing that, in some days, a new tech­ni­cal demo of Lightspark will be released, but this time we’re not talk­ing about basic exam­ples. Lightspark is now mature enough to run a sim­ple appli­ca­tion based on Flex.

Flex is a rich open source frame­work writ­ten in Action­script and devel­oped mainly by Adobe. Even if right now the test appli­ca­tion fea­tures only a progress bar and a square, there is a lot of stuff being done by the frame­work under the hood.

If the frame­work works it means that the engine is now sta­ble enough to move from a pre-alpha to an alpha sta­tus. The design is also now sat­is­fy­ing enough for me to allow other peo­ple to join the project and work on on sub­sys­tems with­out know­ing the inter­nal details of every­thing. As an added bonus pre­lim­i­nary sup­port for the Win­dows plat­form will be included in the release.

The screen­shot above is the result of the exe­cu­tion of my test appli­ca­tion, for curi­ous peo­ple the flash file is gen­er­ated using the mxmlc com­piler, from the fol­low­ing source file

<?xml version="1.0" encoding="utf-8"?>
horizontalAlign="center" verticalAlign="middle">
<mx:VBox x="0" y="0" width="201" height="200" backgroundColor="0x0080C0" alpha="0.8"/>

, , ,

No Comments

The quest for graphics performance: part I


Devel­op­ing and opti­miz­ing Lightspark, the mod­ern Flash player, I’m greatly expand­ing my knowl­edge and under­stand­ing of GPU inter­nals. In the last few days I’ve man­aged to find out a cou­ple of nice tricks that boosted up per­for­mance and, as nice side effects, saved CPU time and added features :-)

First of all, I’d like to intro­duce a bit of the Lightspark graph­ics architecture

The project is designed from the ground up to make use of the fea­tures offered by mod­ern graph­ics hard­ware. Namely 3D accel­er­a­tion and pro­gram­ma­ble shaders. The Flash file for­mat encodes the geome­tries to be drawn as set of edges. This rep­re­sen­ta­tion is quite dif­fer­ent from the one under­stood by GPUs. So the geome­tries are first tri­an­gu­lated (reduced to a set of tri­an­gles). This oper­a­tion is done on the CPU and is quite com­pu­ta­tion­ally inten­sive, but the results are cached, so over­all this does not hit performance.

More­over Flash offer sev­eral dif­fer­ent fill styles that should be applied on geom­e­try, for exam­ple solid color and var­i­ous kind of gra­di­ents. Lightspark han­dles all those pos­si­bil­i­ties using a sin­gle frag­ment shader, a lit­tle piece of code that is invoked on every pixel to com­pute the desired color. Of course the shader has to know about the cur­rent fill style. This infor­ma­tion along with sev­eral other para­me­ters could be passed with dif­fer­ent meth­ods. More on this on the next issue.

There is one pecu­liar thing about the shader though, let’s look at a sim­ple pseudo code:

Selec­tor is a binary array, the only allowed val­ues are zero or one. More­over only one value is one. This means that the cur­rent frag­ment (pixel) color is com­puted for every pos­si­ble fill style and only after­ward the cor­rect result is selected. This may look like  a waste of com­put­ing power, but it is actu­ally more effi­cient than some­thing like this:

else if(selector[1])

This counter intu­itive fact comes from the nature of the graph­ics hard­ware. GPUs are very dif­fer­ent from CPUs and are capa­ble of cruch­ing tons of vec­to­r­ial oper­a­tions blind­ingly fast. But they totally fall down on their knees when encoun­ter­ing branches in the code. This is actu­ally quite com­mon on deeply pipelined archi­tec­ture which misses com­plex branch pre­dic­tion cir­cuitry, not only GPUs but also num­ber crunch­ing devices and mul­ti­me­dia mon­sters such as IBM Cell. Keep this in mind when work­ing on such platforms.

, , , , , , ,


Lightspark second technical demo announcement


I’m cur­rently fin­ish­ing some last cleanups and enhance­ments before releas­ing a sec­ond tech­ni­cal demo of the Lightspark Project. Much time is passed from the first demo, and the project is grow­ing healty. This release aims at ren­der­ing the fol­low­ing movie, selected from adobe demo. The results may not be very impres­sive. But many things are going on under the hood.

The most inter­est­ing fea­ture in this release are:

  • GLSL based ren­der­ing of fill styles (eg. gradients)
  • LLVM based Action­Script exe­cu­tion. Code is com­piled just in time
  • A few tricks are also played to decrease the stack traf­fic tipi­cal of stack machines.
  • First, although sim­ple, fram­er­ate timing
  • Frame­work to han­dle Action­Script asyn­chro­nous events. Cur­rently only the enter­Frame event works, as the input sub­sys­tem is not yet in place. But stay tuned, as I’ve some nice plan about that.

The code will be released in a cou­ple of more days, or at least I hope so :-)

, , , , ,

No Comments

ActionScript meets LLVM: part I

One of the major chal­lenges in the design of lightspark is the Action­Script exe­cu­tion engine. Most of the more recent flash con­tent is almost com­pletely build out of the Action­Script tech­nol­ogy, which with ver­sion 3.0 matured enough to become a foun­da­tional block of the cur­rent, and prob­a­bly future web. The same tech­nol­ogy is going to become also wide­spread offline if the Adobe AIR plat­form suc­ceedes as a cross plat­form appli­ca­tion framework.

But what is Action­Script? Basi­cally it is an almost ECMAscript com­pla­iant lan­guage; the spec­i­fi­ca­tion cov­ers the lan­guage itself, a huge library of com­po­nents and the byte­code for­mat that is used to deliver code to the clients, usu­ally as part of a SWF (flash) file.

The byte­code mod­els a stack-machine as most of the argu­ments are passed on the stack and not as operands in the code. This oper­a­tional descrip­tion — although quite dense — requires a lot of stack traf­fic, even for sim­ple com­pu­ta­tions. It should be noted that mod­ern x86/amd64 proces­sors employ spe­cific stack trac­ing units to opti­mize out such traf­fic, but this is highly archi­tec­ture depen­dent and not guaranteed.

LLVM (which stands fot Low-Level Vir­tual Machine) is on the other hand based on an Inter­me­di­ate Lan­guage in SSA form. This means that each sym­bol can be assigned only one time. This form is extremely use­ful when doing opti­miza­tion over the code. LLVM offers a nice inter­face for a bunch of fea­ture, most notably sophis­ti­cated opti­miza­tion of the code and Just-In-Time com­pi­la­tion to native assemply.

The chal­lenge is: how to exploit llvm power to build a fast Action­Script engine.

The answer is, as usual, a mat­ter of com­pro­mises. Quite a lot of com­mon usage pat­terns of the stack-machine can be heav­ily opti­mized with lim­ited work, for exam­ple most of the data pushed on the stack is going to be used right away! More details on this on the next issue...

, , , , , ,

1 Comment

The Lightspark Project, a modern flash player implementation

lighspark-demo1When some months ago Adobe released the com­plete SWF file for­mat spec­i­fi­ca­tion I though that it would be nice to develop a well designed open source flash player. Now I’ve been work­ing for some time on this idea and I’ve recently relased the code on SourceForge.

The project objec­tives are quite ambi­tious, as the flash spec­i­fi­ca­tion are really com­plex. The project is designed to take advance of the feau­tures present on mod­ern hadr­ware, so it not sup­posed to run on older machines. All the graphic ren­der­ing is done using OpenGL and in the future pro­gram­ma­ble shaders will be used to offload even more cal­cu­la­tions on the GPU. Exten­sive mul­ti­thread­ing is employed to make use of mul­ti­core and hyper-threading proces­sors. I’ll write a more detailed post about some tricky and inter­est­ing part of the project soon.

, , ,

No Comments