Shumway: a SWF interpreter entirely in JavaScript
benjamin.smedbergs.us
benjamin.smedbergs.us
I'll note that Gnash does actually work on YouTube.com, but only because YouTube seems to deliberately serve an ancient version of their Flash player, rather than the latest version with the closed-captions and text overlays and all that stuff.
"Don't get me wrong, they've been noble useful efforts" not "Don't get me know, they've been noble useful effects"
Stupid autocorrect. TBH I prefer typos than autocorrect. At least with typos it looks like a typo instead of making you look like an idiot.
Anyone willing/able to take my (probably irrational) fear away and tell me why this SWF interpreter is a good thing?
I used to do Flash/Flex/Air extensively, and often preached it to my fellow developers, despite considerable resistance. I argued that SWF was fulfilling the cross-platform promise of applets.
And when Adobe managed to mishandle Macromedia's legacy, I was left with much egg on the face. I don't want to go through that again.
That said, good for Mozilla. They really are running with a ton of impressive open source projects.
Similarly, Flash is going down, never to come back (thanks, SJ). So Shumway need handle only the tall head, possibly as a previewer if not a full Flash replacement. The long tail is not too fat, but it will require a plugin for the foreseeable future.
In the far future, archeologists will pore over archive contents at the edge of the Beyond, decoding ancient languages including JS and SWF, leery of evil transcendant malware ;-).
/be
It wasn't hard to write it myself (I'd guess about 40 hours for everything), but if we were going to make HTML5 games, I'd definitely consider this library.
It is an exporter from the Flash tool to a separate format, not a SWF file interpreter, so it has a different set of tradeoffs.
That said, is the payoff of implementing this enormously involved solution really worth it? I don't know why I feel like this, but something deep down pains me when I think of the man hours and frustration that had to have gone into something like this. Does anyone else know what I mean?
.. definitely skating to where the puck used to be.
We have both an interpreter for ActionScript bytecode as well as a compiler that compiles that bytecode method-at-a-time to JavaScript using a restructuring approach like emscripten's relooper.
Disclaimer: I work on Shumway.
(I'm actually pretty young, but I've done work with microcontrollers, which feels like stepping into the past. I know a guy in his late 20s who steadfastly refuses to switch from assembly to C, for reasons that come straight out of the 70s. It's a strange world we live in.)
So the advantages of Flash over JS (in my opinion) in short are: better language, better APIs, no tweaking for different platforms.
Anyway, if Shumway was fully featured, it would definitely be a big benefit. But if it doesn't work cross-browser and doesn't support all the features of Flash/Actionscript 3, then you're losing some of the main advantages Actionscript 3 gives you, and you're almost just as well off righting things in JS.
/be
Subtle differences in implementations, you say? That is called the open web. Come on in, the water's fine. Pay no attention to the drowning plugins over in that cold corner...
/be
It seems as if JS is the future, and that's not necessarily a bad thing, but it would be nice if JS had a few more features to make it easier to use. I personally wouldn't be opposed to starting clean (with something like Dart) but that's probably unrealistic.
Overall, the reduction of plugins is a good thing, who doesn't like less security holes, less software to update, etc. But it's also a bad thing if we lost features off stuff, lose functionality, loss cross-browser capabilities etc.
Also, can't believe I said "righting" instead of "writing" in my last post. That's quite cringe-inducing.
A worthy goal, but I hope they don't let NIH set them years behind the curve.
The whole point is that doing it in JS avoids the need for a native code plug-in, which cuts off an entire avenue of security problems. Same story as PDF.js.
The applications of Flash make it a better candidate for native code instead of the performance wreck of a from-scratch JIT-on-JIT solution. I think it's a great demo and probably a useful experiment that can improve the quality of Firefox's JavaScript compilers, but I don't think it's a very serious candidate to replace Flash Player for its most common strongholds (for instance: that simple little car demo runs at 20fps on my machine, which I built last month and has an i7 3770K). And that's really what we need right now.
The excuses to write this in JavaScript are pretty flat. You don't think they can figure out how to make an NSAPI plugin reasonably secure? You don't think they can get the code portable enough to work on multiple platforms? The biggest issue is probably mobile since many machines there use ARM, but Lightspark uses LLVM as its backend, which already supports ARM. I'm confident Mozilla's engineers can figure that out and give us a real replacement for the Flash player.
I don't mean to imply that this project isn't impressive -- it is. But I hate to see them duplicate so much effort for a solution that is, by nature, performantly disadvantaged. We need a serious challenger to Flash Player (we've had enough toys) and Mozilla is in a good position to provide that, so I hope they choose to do so.
>They don't include animations, they don't accept user input, they don't connect to servers and stream files and send updates
A PDF file is much more than just words and pictures. There are forms which accept user input, weird embedded content, and other strange things. Although I am not familiar with the spec, I have seen the features that Adobe Acrobat lets you do with PDFs and it seems pretty monstrous.
To clarify, there are several security issues that arise from all of this [0], and as others on this page have pointed out, that is a good reason to make use of the existing infrastructure around browser sandboxing.
Why are we so afraid of native code these days? Firefox already runs plugins in a sandbox, and has done so since 3.6. There is more complexity and opportunity for screwups in unmanaged code, yes, and for a PDF JavaScript is just fine, but for something that requires a powerful, fast VM capable of real-time graphics and real-time user input without lag or freezes, it is silly to write off the benefit of performant native code just because Adobe's plugins are rife with security holes, which I believe is what is happening here.
Nope.
> You don't think they can get the code portable enough to work on multiple platforms?
Not on platforms that expressly disallow it, e.g. iOS.
Flash performance is a combination of code and graphics. Taking LightSpark or Gnash would not give you something that integrates in an optimal way with the browser's hardware accelerated graphics systems, you would need to do a lot of plumbing for that. So yes, the C++ might be faster than JavaScript, but the graphics might end up making it less performant overall.
Plus, the native code is nonportable and nonsandboxed. Portability might be the simpler of the two, but it is still not trivial these days to maintain a single C++ codebase across multiple compilers and OSes. Sandboxing is the big problem though: A fast ActionScript implementation must have a JIT, and JITs are extremely hard to secure. The browser already has a dynamic language JIT (for JS), so using that instead of adding an entire new one is far preferable. In addition, the C++ code must be secured too which takes effort and introduces risk.
So there are very good reasons for going this route. But I agree there are tradeoffs and benefits the other way too.
I know there's also Gnash, but I haven't tried it in a long time, and I'm led to believe it is far from feature complete. Hopefully this project can push further.
http://en.wikipedia.org/wiki/Lightspark
"Lightspark is a free and open source SWF player"
Still in beta.
This kind of emulation is a good demo , but doesnt work in the real world. Why whould i use that ? old browser will never support that tech ( < IE9 ) but they support flash , recent browsers dont need flash , what's the point ?
It makes more sense to build tools similar to flash IDE that can export to HTML5 than wasting time trying to make legacy code run slow and blow up to the user's face ...
been there , done that ...
1) If it works, then it shows how far browser technology has come. Real examples are meaningful.
2) SWF files are content. In a Flash-less world we'd have no ability to experience Dice Wars or most Kongregate games or http://raditts.com/phyles/xiao3.swf Consider this project an emulator for old things. :)
I was looking for this movie. Thanks!
- Linux
- Win8 Metro, depending on the whitelist contents
- iPad
- iPhone
- FirefoxOS (neé B2G)
As Stan the Man says, 'nuff said!
/be
On the desktop, it's a bit of a different story. Chrome supports Flash on Linux quite well. Internet Explorer also has Flash baked in. There is some whitelisting if you are in "tablet mode"-- or so I am told. It seems like for a normal computer you should be able to turn off tablet mode, though.
I wish Mozilla had put some effort into contributing to Gnash or swfdec. There really wasn't, and isn't, a good flash decoder that isn't derived from Adobe's codebase. All the ones that exist now are toys. I have a feeling that this effort will be no different. I hope I'm wrong.
@supercoder's point about skating where the puck used to be has truth in it, and we do not aim to over-invest in Flash via Shumway now (and we avoided it before; perhaps we should have done more, but the only temporarily-winning effort I know of was Chrome's, which required a business deal with Adobe and a tremendous amount of engineering effort on Google's side).
On the other hand, as Jet Villegas's blog post points out, we also uplift the web and smooth out uneven APIs and performance curves by researching Shumway. If Flash requires some greater JS performance, or some API gap to be filled, Shumway is the most direct way to find out. It's well within Mozilla Research's ambit, and not backward-looking, to explore this space.
Finally, if we can deploy Shumway as a previewer and reduce actual Flashplayer plugin instantiations greatly, with as good or better user experience in terms of jank, CPU utilization, battery life, etc. -- and with some black-video-frame-of-death saves on my iPad, should Shumway be supported there -- that helps in the coming years as Flash lingers on in the "desktop web".
But make no mistake: the growth curve for mobile devices and the lack of Flash there will kill Flash. All those restaurant sites that sunk their discretionary web content development budgets in Flash years ago? They are re-investing rapidly to work on iOS devices. I don't see Flash rallying on desktop, or even via Air on Android.
Add this all up and I believe Shumway can avoid the forever-a-toy status. Flash is proprietary tech, in spite of SWF being opened up in recent years. Its single main implementation code is its spec. This hurts when the single implementation is evolving rapidly, but as that implementation slows down and (outside of Air and games, let's say) declines, the 90%-coverage "toys" become real tools, with the right integration.
This could have applied to Gnash or swfdec in the past, but at significantly higher cost, not only in direct engineering costs and opportunity costs to web-perf/API-uplift, but also in securing yet more piles of native VM code.
/be
1. You mention that this can help in terms of CPU utilization, battery life, etc. Would be great, still today, the very simple (non AS3/vector based) Racing game (http://mozilla.github.com/shumway/examples/racing/) you are running through Shumway requires around 70% of CPU usage on my MacBook Pro against 11% with Flash Player. A game which would consume even less in Flash Player if it used AS3 and simple bitmap blitting techniques. Yes, JS performance will improve, and efforts like River Trail are promising, but we are still far from that, I am a little worried we are setting the wrong expectations here.
2. The restaurant websites. Yes, there are a lot of these restaurant websites using Flash. And to be fair, they should never have used Flash for that. But you are right most of them are porting these to HTML and it works nicely. But fortunately Flash on the web is not used for restaurant websites only, especially games. Today Flash Player is used to power 9 of the top 10 Facebook games with content like FarmVille 2, CityVille, Kings Road, Ruby Blast, Angry Birds targeting around 30 million daily users are powered with Flash Player using Stage3D and without Flash, we would all be playing Racing games like the one mentioned earlier. Or maybe faster games, but with NaCl in Chrome only? ;)
3. You don't see Flash rallying on desktop, or even via Air on Android. Thanks to Stage3D, AIR is actually becoming more and more serious for game developers. Most developers wanting to develop games on desktop, iOS and Android are facing big issues when it comes to fragmentation and AIR solves that. All the mobiles games here http://gaming.adobe.com/showcase/ are using AIR.
Thibault
2. Facebook games running Flash are still a huge % of crashers for all Flash-enabled browsers. We'd like to help that. As browsers like Chrome sandbox away Flash's ability to be faster than the browser (i.e no more direct GPU access on Pepper) then Shumway becomes much more attractive, especially on mobile platforms for which there is no Flash Player.
3. SWF as a packaging format for app store deployment is a pale shadow of what we set out to do when we started working on it years ago. SWF could still outlive us all (like JPEG, HTML etc.) Shumway may well be the best bet to keep it alive.
--Jet
2&3. I did write "(outside of Air and games, let's say)". Did you miss that?
See also Emscripten, which produces GC-free well-typed JS. We're also working in Mozilla Research to show Emscripten + JS can competes on performance, and excel on reach, with alternative single-browser and proprietary approaches.
/be
2/3. Yep, I missed that. Fair ;)
Yes, I have been following Emscripten and it is promising. No doubt clearly on the excel on reach just some remaining doubts on the performance and CPU/battery usage.
If you guys truly want to have this valuable, also make sure the entire system is consistent, like Flash, and not just in Firefox.
As I said, it is a neat research project, I will keep watching Shumway grow :)
Thibault