mbebenita

This is used only for development. The preference allows you to access privileged browser APIs, like triggering a GC at exact points in time. This is useful when running benchmarks to reduce the noise causes by a previous run.

The preference is named as such to prevent people from being tricked into turning it on.

Canvas perf has almost caught up, ... what's lacking is tooling.

Here is Shumway playing back this fantastic animation:

http://www.areweflashyet.com/shumway/examples/inspector/insp...

Overall we had a good experience. There were some pain points at first with compile time, but that was greatly improved with the new TS compiler.

We can detect when bytecode is not well formed and fall back on interpretation, which can handle these nasty cases. This is more of a problem for AVM1 than AVM2.

Thanks for the great tool, we used it quite a bit when we first started working on Shumway.

Shumway falls back on an interpreter if the control flow is not reducible.

It was designed by the Shumway team as a SWF that uses many of the Flash features. It's full of easter eggs.

Flash has a retained mode graphics API and a fantastic scan-line rasterizer. Each pixel is drawn once which is not the case for HTML Canvas where there is usually a lot of overdraw.

It's all about graphics perf, not AS3 vs JS anymore.

ActionScript compiled to JS is not the performance bottleneck. In many cases it is faster than ActionScript ever was simply because of the huge investment most browser vendors have put into their JS engines. Flash-like vector graphics is what's hard to emulate on the web today. If you only care about moving spites around, then Flash, Shumway and C++/OpenGL will be mostly GPU bound.

Flash got a lot of things right, both the SWF file format and the authoring tools are pretty good. There's not much sense in re-inventing it (we could do without ActionScript though).

For the most part, yes. Some things are hard to emulate, Weak References, E4X which is still wildly used, AS3 Namespaces, and all the graphics APIs. Flash just has a very different rendering model that doesn't easily map to Canvas.

The hardest part about Flash is understanding how timeline animations interact with AS code: events, object construction order, for all versions of Flash. Shumway supports all SWF versions and the the three programming languages that are supported by the Flash player: AS1, AS2 and AS3.

Shumway dev here. There are a lot of fascinating aspects to Shumway, it's basically a browser inside a browser and there are a million things to do, so ping us on IRC if you'd like to get involved, #shumway (irc.mozilla.org).

In the case of Shumway, building everything on top of the web stack made it impossible to resume much of the previous work. It also turns out that if you want to build a Flash replacement, you have to reverse engineer 15 years of development on a poorly documented closed source system. If you're not bug for bug compatible you won't have a working Flash player, which is probably what stumbled a lot of projects in the past.

We do in fact translate AS (AVM2) bytecode into JS source. We can't target JS bytecode because we would like Shumway to run on every browser, not just Firefox. Maintaining one JS VM is a lot easier than dealing with two. Although it is fairly tricky to emulate AS features in JS, it's significantly easier than rewriting / maintaining a VM like Tamarin.

This is what Shumway does, it has both an Interpreter and a JIT.

Shumway runs in every browser, including IE. The extension however is Firefox-only, but it should be easy to make it run in Safari or Chrome. We're just not familiar enough with those code bases to do it ourselves. It involves some intimate knowledge about how to intercept Flash player initialization.

I work on Shumway, and we would love to get more complex Flash games running. Would you and your company like to help our team get these games running? Performance is a hit or miss, sometimes we can be really fast, sometimes really slow, it all depends on either:

1. We haven't implemented some feature well enough. 2. We can't implement a feature in JavaScript/HTML5 and we have to emulate it in a very slow way. In these cases, we can either improve the Web Platform to support these features natively, or work with various game developers to avoid using them.

Shumway compiles ActionScript bytecode to JavaScript source. It cannot target ASM.JS because not all ActionScript code is typed. The goal of Shumway is to identify what is missing from the web platform and fix it, so we're working on improving graphics performance.

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.

"require('memory')" gives you back a JS module that's written in LLJS (http://git.io/vHeH2g). It exports several typed array views and a few functions like malloc() / free(). It's all JavaScript, nothing native.

Relying on JS function calls and variable declarations is actually more efficient in this case since the underlying JS JIT can perform a lot of optimizations (SSA / Register Allocation). We do stack allocation for structs and local variables for which you need to take the addresses of.

The "let" keyword is left in there because we wanted to stay compatible with JS. So any JS program is also an LLJS program. This way it would be easy to integrate into an existing code base. As for the "let" vs. "var" debate, we chose "let" because of its block scoping semantics and because we didn't want to let variable declarations alias each other with different types.

The benefit over Emscripten is that LLJS makes it easier to mix JS and C-like code and skip the C/C++ tool chain. Of course, the drawback is that you miss out on all the LLVM optimizations.

The size can be adjusted to whatever size you need. In principle this can be done automatically by malloc by hot-swapping the typed array with a larger one.

I totally agree, but it just sounds weird when you say it, JS* vs. *JS.

Well, the * was supposed to be a pointer. JS is dereferencing JS, so JS would be more appropriate since it implies static typing and pointers, but it sounds awkward when you say it, so we went with *JS for now.

Actually, you could build something like Valgrind quite easily. You can replace the underlying heap with a JS proxy and trap all read/writes, it would be a fun project.

Why not extend the typed array API to include SIMD operations on multiple array elements, we can compile to use those and special case them in the JIT.

Give it another try. We made a few small improvements that turned out to be quite significant.

You should give the latest version a try, we improved the performance considerably.

Well, for instance, we can take advantage of hardware features like shaders in WebGL or make use of WebCL, rivertrail, etc., which are all available to JavaScript. Perhaps we may not reach the performance of native codecs, but we can get close enough.