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.
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.
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.
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
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.
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.
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.
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.
