Open-Source JavaScript Flash Player (HTML5/SVG)

gbutler69 writes "Someone has gone and done it. Tobias Schneider has created a Flash player written in JavaScript targeting SVG/HTML5-capable browsers. It's not a complete implementation yet, but it shows real promise. A few demos have been posted online. How long before HTML5/SVG next-generation browsers like Chrome, Firefox, Opera, Safari, Epiphany, and other Web-Kit based browsers completely supplant Flash and Silverlight/Moonlight?"

Comments

Re:This is great!

[TheRaven64]

Why? Most of what a Flash applet does is run ActionScript, which is a dialect of JavaScript. The drawing in this will be done by the browser, rather than by a plugin, and the code will be run by the browser's JavaScript engine instead of the plugin's one. If anything, you'll see less memory usage because you'll only need one JavaScript VM instead of two.

OMGWTFPDF

[shutdown -p now]

Great! Now, please, can someone write a PDF renderer in JS + HTML5 Canvas, so we can get rid of the browser killer plugin that is any PDF viewer out there?

Before you get all excited...

[Qubit]

...according to the article his code only supports the SWF 1.0 format, and he's currently working on adding support for the SWF 2.0 file format.

Adobe Flash 1 and Flash 2 (which I'm going to guess might roughly line up with SWF 1.0 and 2.0), were released in 1996 and 1997, respectively. As in, over a decade ago.

Much larger, more long-term projects like Gnash have been working on completing a compliant Flash client for several years and still don't have support through Flash 8, 9, and 10. It's apparently a lot of work to support all of the different pieces of Flash, especially as it turns out that the SWF spec has been completely overhauled several times over the past decade, resulting in wide differences between things like ActionScript 1, 2, and 3.

So while I wish this effort all the best, it would require a lot of time/energy/talent to make this client have the coverage necessary for, say, internet video sites to work.

Re:Now if they could

[clang_jangle]

flash based cookies, which are not that easy to block and/or delete for the user, are used by all advertisers and other bastards, spying on you

Trivial to defeat, at least in *.nix. Just remove all write permissions to the ~/.adobe and ~/.macromedia directories, after deleting all the cookies within. Buh-bye, flash cookies. Also makes flash work noticeably faster.

Re:This is great!

[TheRaven64]

It's worth noting that Adobe and the browser makers optimise their VMs for different requirements. Flash tends to run very long-running things, like games which use a big chunk of CPU for several minutes at a time. JavaScript in a browser tends to do relatively simple things and uses a tiny bit of CPU. The main requirement for Flash is efficiency of generated code, while for JavaScript it's load time. The test suite that the WebKit team use runs in a couple of seconds on a decent computer, while a typical Flash game will often take at least 10 seconds to download all of the image and sound files that it needs. This gives the Flash VM a little while to spend compiling and executing the code.

There are, roughly speaking, four ways of implementing a programming language, although the boundaries between them are sometimes blurred. From slowest to fastest, these are:

1. Interpreting the AST (or even parse tree). Whenever you run a bit of code, you do a traversal of the tree and execute each node in turn. This is how JavaScript was implemented in browsers until a couple of years ago. It's very slow, because something like 'a = b' involves three AST nodes and so you need at least three function calls for a trivial assignment.
2. Compiling the AST to bytecode and interpreting the bytecode. Bytecodes are instruction sets for virtual stack machines where each opcode is one byte. You can implement them with a jump table, so the interpreter is fast (typically 50% native speed or more). A simple assignment would be a push value, push address and pop value at address bytecode instruction, which would expand to half a dozen or so native instructions. Significantly faster than interpreting an AST.
3. Just-in-time compiling to native code. Functions (or traces in something like Tamarin) are compiled to native code as they are needed, or after running them in an interpreter a few time and getting profiling information. This can produce the fastest code, because it can be tailored for that specific run of the program, but the cost of generating the code has to be added to the cost of running it every time that you run the program. Great for long-running programs, not so good for other things.
4. Statically compiling to native code. This produces good code. It doesn't have as much profiling information, but it also can spend longer optimising because the end user isn't waiting for the compiler to run, so it tends to be faster than JIT compilation in practice.

Tamarin, the VM in Flash, uses the JIT approach, while the WebKit JavaScript VM is a bytecode interpreter.

One of the hippyware projects that I maintain is a compilation infrastructure for dynamic languages, with an AST interpreter a JIT and a static compiler. On one of my test programs, running the JIT-compiled code took 0.023 seconds, but compiling it took over 2 seconds. In contrast, running it in the interpreter took about 0.9 seconds. Although the JIT-compiled code was significantly faster than the interpreted code, the total running time was faster. If you added a loop so that the test program ran twice, it was a bit faster in the JIT, and if you made it loop ten times it was significantly faster.

For most browsers, the JavaScript for a given page uses a fraction of a second of CPU time, so spending even one second generating optimised machine code from it is not productive. In contrast, Flash code can spend several CPU-minutes running, so if spending five seconds on optimisation makes it twice as fast then it's time well spent.

Re:This is great!

[h4rr4r]

How about just posting the damn videos? All modern browsers will play video fine.