Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Shumway: a SWF interpreter entirely in JavaScript

benjamin.smedbergs.us

Post reply on HN
Print view View original

21–30 of 61 posts

Re: Shumway: a SWF interpreter entirely in JavaScript

#21

Post by nnethercote »

cookiecaper wrote: post #17

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 i…

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

Re: Shumway: a SWF interpreter entirely in JavaScript

#22

Post by pjscott »

ChuckMcM wrote: post #12
syg wrote: post #5

Earlier quoted context omitted.

To be more precise, JITs on top of JITs. :) 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 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.)

Re: Shumway: a SWF interpreter entirely in JavaScript

#23

Post by [deleted] »

ChuckMcM wrote: post #12
syg wrote: post #5

Earlier quoted context omitted.

To be more precise, JITs on top of JITs. :) 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 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.

[deleted]

Re: Shumway: a SWF interpreter entirely in JavaScript

#24

Post by cookiecaper »

nnethercote wrote: post #21
cookiecaper wrote: post #17

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 i…

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

Re: Shumway: a SWF interpreter entirely in JavaScript

#25

Post by camus »

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

Re: Shumway: a SWF interpreter entirely in JavaScript

#26

Post by chadaustin »

camus wrote: post #25

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 ( 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 t…

It's not a waste of time for two reasons:

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

Re: Shumway: a SWF interpreter entirely in JavaScript

#27

Post by freditup »

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.

Re: Shumway: a SWF interpreter entirely in JavaScript

#28

Post by azakai »

cookiecaper wrote: post #17

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 i…

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

Re: Shumway: a SWF interpreter entirely in JavaScript

#29

Post by pserwylo »

cookiecaper wrote: post #24
nnethercote wrote: post #21

Earlier quoted context omitted.

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

>A PDF file is just words and pictures on a page

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

[0] - http://duckduckgo.com/?q=adobe+pdf+vulnerabilities

Re: Shumway: a SWF interpreter entirely in JavaScript

#30

Post by BrendanEich »

freditup wrote: post #27

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…

You seem up-to-date on AS3 but not on JS. JS has typedarrays (even in IE10) now.

/be

Post reply on HN