I have good hopes for this (Mozilla's HTML5-based PDF reader is my favourite PDF browser plugin), but I'm a little worried - there have been a lot of Open Source Flash reimplementations, and so far as I can tell they all have early success and pretty demos of older Flash content, but are completely useless on most real-world Flash usage, like nearly any site that shows a video.
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.
There's another use case for this: Write a Flash app targeting both Swiffy and Adobe. The Swiffy part is easy since you can serve your own known-compatible or locally-hacked version of Swiffy used to run your app.
that's the point , you cant keep up with the latest flash version = fail . You cant get good performances = fail , you cant run it on old browsers that dont have flash = fail .
Nobody needs that. This has already been done , all the projects have failed. If i had skills i would not waste my time trying to fit a triangle in a star , i would develop tools to make perfect fitting stars. That's what people want.
There's no need to keep up with the latest flash version. If you can render 90% of the legacy content out there (ads, animations, simple games) it's already good enough. You can always fall back on the real Flash player if you need to play a fancy game.
let me run the top 5 facebook games ( made in flash ) and we'll see about the 90% content people can actually use with that!!!
I say that's a stupid project, already been done but nobody's using it, or even care, because it doesnt work !
Interestingly this has been my opinion of all the projects that attempt to create a bridge between native mobile APIS and javascript like phonegap and trigger.io. Don't get me know, they've been noble useful effects, but a lot of that effort should have going into projects like WebKit and Firefox to bring those native APIs to the browsers themselves.
Being more of a designer than a developer, I've got to admit that the thought of second wind for Flash kind of scares me. I've never liked Flash, mainly because historically it wasn't as "open" as HTML, Macromedia Flash (I know, right) crashed a lot, as well as the general abuse of Flash found all around the web in the late 90's/early 2k.
Anyone willing/able to take my (probably irrational) fear away and tell me why this SWF interpreter is a good thing?
Even though I think this is a cool project, I agree 100% with your fears.
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.
No second wind here. Think instead of pdf.js and how it relieves you of the bloated security hole called Reader. PDF is a large format (extensions include SWF!) but pdf.js need not handle all of it to be useful in minimizing Reader activations.
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 ;-).
Even ignoring the Player / AIR runtime, Flash is a fantastic tool for animation authoring. For example, our game artists use Flash to create SWF clips which we then export and playback with an internal format and C++ engine, supporting a fairly limited subset of all SWF features. This content ranges from UI layouts and transition animations to particle special effects and storytelling cutscenes.
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.
I actually don't think we're sharing any code with Gordon. But yes, the name is this obscure transitive-closure reference: (Adobe) Flash -> (Flash) Gordon -> (Gordon) Shumway.
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?
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.
I could give you the old guy's rant, "Back in my day we were happy to have only one 'core' and if it ran at 8Mhz it was in turbo mode!" :-) Its an amazing piece of work.
Bah! Back in my day, we counted ourselves lucky if we had an 8 MHz crystal clock. I had to make do with an uncomfortably temperature-dependent RC oscillator running at what I lightheartedly hoped was about 4 MHz.
(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.)
The main advantage to Flash is that you get a much more mature language (Actionscript 3) to work with over JS and you also get a whole host of great APIs that are easy to use. (From ByteArrays, to the Camera class, to different blend modes and filters, easy Bitmap manipulations, etc.). Now, JS is starting to implement some of these things which is good, but they still vary across browser, only work on the most modern browsers, etc.
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.
First of all, there are more things than typed arrays (vectors) in AS3, the main thing being a consistent runtime. Also the way you structure an AS3 project is different since the language supports packages/classes etc while in JS you (for better or worse) don't have these concepts so you end up with many different code styles. Even though browsers implement the some of the features, there are subtle differences in the implementations. This results, in real world scenarios, that this stuff are being abstracted away, layers and layers of abstractions, libraries for everything. I have my doubts that this SWF interpreter can be efficient.
There are too many layers in all doomed software, whether written in JS or AS3.
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...
Sure, but from what you said I'm guessing that they don't work in IE9, which is what I mean about cross-browser issues. Plus, TypedArrays are somewhat clumsy maybe?
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.
While I understand that they want something that doesn't require installation, I think it's kind of sad that they felt they couldn't pick up on Gnash or LightSpark or some of the other good open-source Flash work out there. This is a nice concept demo; maybe they will choose to work on a grown-up Flash player instead now. Performance is bad enough without putting the JavaScript intermediary in there, and LightSpark is super promising.
A worthy goal, but I hope they don't let NIH set them years behind the curve.
> Performance is bad enough without putting the JavaScript intermediary in there
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.
> it's kind of sad that they felt they couldn't pick up on Gnash or LightSpark or some of the other good open-source Flash work out there
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.
There's a big difference between displaying a PDF file in JavaScript and compiling and displaying an active, real-time Flash game in JavaScript. A PDF file is just words and pictures on a page, same thing browsers have always done. They don't include animations, they don't accept user input, they don't connect to servers and stream files and send updates, and they definitely don't run real-time graphics code or path finding and collision detection algorithms.
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.
Right, but what percentage of the esoteric features technically supported by PDFs are actually in use? With the exception of forms, the huge, overwhelming majority of PDFs never use things like embedded objects (which, funnily enough, can sometimes be Flash files). And forms are definitely doable in a JavaScript PDF reader; they are, in fact, probably easier than in a native PDF reader since you'll be able to use HTML. So in JS, they can display almost any PDF in the world with no trouble at all. How many Flash programs are more complex than that little car demo, which runs slowly on my top-of-the-line hardware?
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.
We already have a thing that's capable of real-time graphics and real-time user input, it's called a web browser. This is simply leveraging that to run a different set of input.
This is pretty exciting. Flash player has never been my favourite piece of software, so having a reasonable alternative would be fantastic.
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.
The demo errors out in Safari, apparently due to some weird issue with defineProperty and read-only properties. As big as a HTML5 fan as I am, considering Flash's cross-platform consistency, it's a bit ironic...
this project is a waste of time. The problem is not the player , but how flash can output content that use standard browser apis.
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 ...
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. :)
Just to clarify, those are Platforms where the Flash Player / Browser plugin is not supported or available. You can use the Flash development and authoring toolchain to develop content for many of those platforms.
I think we pretty much all agree that flash is dead on mobile. That includes iPad, iPhone, Android, and so forth.
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.
I wish I had a dollar for every time someone wished that Mozilla did more anti-leveraged work in the past.
@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.
I seriously believe that Shumway is a very cool research project to demonstrate what is possible in modern browsers. But I just want to highlight a few things:
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.
1. CPU utilization will get better. We have a lot of low-hanging fruit yet to harvest (eg. the playerglobal built-ins aren't JIT'ed yet as we dogfood the interpreter.)
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.
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.
1. Ok, thanks for the info. Just tell people, cause people will get defensive otherwise.
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 :)
My point is we dont need yet another emulator , but tools that help dev/designer/whatever great great content for the web. Nobody wants to run legacy code forever ,and i'm sorry , but the emulator doesnt work on any of my devices. So stop wasting your time , create software that people can use, not emulators nobody's going to run.
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.