Slashdot videos: Now with more Slashdot!

View

Discuss

Share

We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).

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?"

Welcome back to 2008. There was major improvement in javascript engines during 2009 in all other browsers than IE and Firefox. Chrome and Opera have incredibly fast javascript renderers and they're pushing it even more in next Opera version.

Welcome back to 2008. There was major improvement in javascript engines during 2009 in all other browsers than IE and Firefox. Chrome and Opera have incredibly fast javascript renderers and they're pushing it even more in next Opera version.

Firefox 3.5 was released in June, with new Javascript improvements via Tracemonkey (a JIT compilation engine) that make it comparable with Chrome. I just tried out the demos and Firefox does not noticeable lag and it did not use more than 10% CPU, which is about the same as a normal Flash video for me.

IE8 came out in 2009, and from my understanding it massively improved JavaScript performance. Still not on par with the competition, but within an order of magnitude. FF 3.5 (with TraceMonkey) was released in 2009 as well, and had a similarly impressive boost to JS performance. Just because neither is quite at a Chrome level doesn't mean they aren't *much* faster than they used to be.

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.

Not true at all. Javascript engines are getting faster, a lot of effort, time and money is being put into making that so. Googles V8 engine for example. Also paired with the fact that HTML5 introduces a notion of concurrency into Javascript this is then even less of an issue.
~Unfortunately most people still think circa 1998 when talking about Javascript. Wrong. Javascript is key to the future of the web and not heavy inefficient server side solutions.
Have a look at say node.js and see if you still think

What about open sound standards? Can the <audio> element of the HTML DOM support playing multiple instances of one sound at once, or varying the playback rate or volume of audio, or synchronizing vector animation to the audio? The common uses of audio that I've seen in SWF objects on Newgrounds makes use of all of these Flash Player features.

The main uses that come to mind are video, audio, and non-video animation. The company I work for makes online training courses which are all done in Flash, there's no suitable alternative to Flash in that context (unless you count Silverlight, which I don't).

The answer to your question relies on a proper definition of "we". "We", to you, means everyone who uses the Internet. However, "we", in reality, are a small minority of people who know what they are doing and what they are talking about.

It is similar to ipv6 - change can only happen at the level of big companies (or, in this case, video hosting sites like Youtube) who don't want to change for various reasons. HTML5 took forever to get here because it was designed to be easy to transfer to, but people ha

Sure, in theory. But clients often see something they think is sexy on the Warner Bro.'s site for some new movie or a really cool sports game on ESPN and they want something similar. Then trying to get them to understand that their desire for something similar on their site requires using something despised by a large number of people (i.e. Flash). Then you're in a tight spot. Most times, my clients want the neat shinies they see, despite the fact that it actually goes against the first requirement they giv

Bite your tongue. If anything replaces Flash it will be Silverlight. Do you really want Microsoft controlling the non-HTML portion of the Web? Do you really want Microsoft turning the Web into a Windows-only experience? Because that's what's going to happen if Flash is supplanted. Be careful wht you wish for.

Can't we ditch JavaScript and _just_ use Flash - a nice blockable scripting engine that isn't integrated so deeply with HTML that disabling it breaks scores of sites with otherwise useful information?If I want maximum battery life I block scripting, period. If I want fancy UI doo-dads and continuous browser-server communication I can enable Flash. What I don't want is great gobs of busted HTML when I don't want to run any kind of scripting engine. Just because you can doesn't mean you should, I'd like it

Maybe that won't be so bad then. Javascript will mainly just interpret the binary flash file and represent it back to the browser as svg +javascript. It doesn't have to render each frame of the movie, it could just tells the browser the key frames and the general instructions of how to get from key frame to key frame. Not going to be as fast as flash, but it still has a chance of not being pear pc* slow.

For you younger folks or older folks with limited mental faculties, Pear pc was an emulator of a powe

Clearly you aren't on a mac. I can tell a website is running flash with my eyes closed on my mac because the fans turn on. Other than rendering large amounts of video, flash is the ONLY thing that causes my fans to come on with any sort of regularity. This is not a browser specific issue, it is a adobe wrote and anwful flash implementation for mac. I am all for a javascript replacement for flash if it gets rid of the adobe crapware. Adobe flash for mac might actually be worse than real media player was on

I mean its great and all, it means that this new "flash" player will probably end up working across all the browsers eventually, and without the security vulnerabilities and downsides to the flash plugin.

But I think in the end - Flash is still going to be used to create the content. Adobe will put more effort into optimizing it, and then a lot of "regular" people will just end up prefering the flash plugin.

I mean Gordon is a server side installation, which means I personally can't start using it everywhere

I've found that I can inject just about anything I want into the browser that I run on my machine, isn't this the point of a bookmarklet? For that matter isn't that how most browser add-on's work, including the existing flash player? They extend the page as sent from the server (which by it's nature is either textual or binary, but is in no way inherently feedback oriented).

and java isn't slow. It currently runs about 2-3 times slower than c++ for nearly all applications, 2-3 times faster than.net CLR and about 10-20 times faster than scripting languages. In some case, though admittedly rare, java exceeds the performance of c++.

For long-running, non-interactive applications, sure. As you say, in terms of raw performance Java is only 2-3 times slower than C++, which still makes it faster than CLR or most scripting languages. However, in the areas of start-up time and GUI performance Java's reputation for poor performance is well-deserved. This may not impact its usefulness for servers, but it makes all the difference in the world when it comes to desktop applications.

Don't know why you got modded Offtopic when your point is a fine response to the GP. Java does have fine performance (for most purposes), but it suffers from start-up times getting the virtual machine up and running. People have a simple reaction to such programs. They start it, they find themselves waiting for it to get going, and they say: "This is sooooo slow." Doesn't much matter what happens after that. The impression is made.

I don't see why it would be slow, necessarily. A browser's javascript engine replaces the flash's actionscript, and browser rendering using svg vector graphics replaces the flash vector graphics. It's not a big change. "will be quite slow with any complex SWF" describes Flash pretty well.

Problem is, when you are light years behind the competition, a high rate of improvement still requires a long time for catch-up (if it ever happens, given that the competition are all moving targets themselves).

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:

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.

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.

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.

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.

I'd mod you up if I could. That said, don't some JIT VMs do both interpretation and compiling. Like, after a certain hunk of code has been hit 10 times, it compiles it. That would seem to be ideal for browsers as well. Hell, anything that improves that 5 seconds my browser is frozen for after loading a Slashdot page would be awesome.

I would say that the main thing holding it back is the total lack of a high-performance way to address bytes in JavaScript. The state-of-the-art for decoding binary protocols in JS is to use charAt and charCode to grab a character at a certain offset in a string, which throws off a phenomenal amount of garbage to be collected and is tremendously slow as well.

Why do they generate garbage? This was a solved problem in Smalltalk-76 (and Smalltalk copied it from Lisp), and I use the same solution in my Smalltalk compiler. Small integers are treated as immutable objects and are squeezed into a pointer (low bit set to 1, since all objects must be word-aligned and so always have their low bit set to 0), so you can store 31- or 63-bit integers without needing to allocate an object (or involve the GC). A trace VM can easily inline the charAt() method, so apart from t

I'm using FF 3.5, so its not so bad - I might try chrome in a few days (after the slashdotting) to see what its like there.

The answer about byte manipulation was an interesting one, as a C/C++ dev I take such things for granted, but "generating a lot of garbage" means there's a lot of string copying going on under the covers which I know is a tremendous hit on system resources. I'm hopeful that it'll be improved though - Google has too much at stake:)

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.

The ironic part is most of the Acrobat reader vulnerabilities are accessible due to javascript. Disable javascript support in the reader and you are pretty safe from most of the exploits. I don't know if that holds true for the flash player though.

I checked out the posted demos [paulirish.com] on my iPhone. Although they were a tad sluggish (particularly the star fade-in on the first demo), frankly, it wasn't bad. Some of the sluggishness could have just been because the demos are getting Slashdotted.

Personally, I'm a little more interested in PhoneGap [phonegap.com], which lets you use JavaScript to create iPhone apps (outside the browser).

While JavaScript runs on the local box, Flash typically begins running as it downloads, so an animation may stutter if it is struggling with the download. I was assuming that this remained true with this JS interpreter, and surmised that some of the sluggishness could have been due to the SWF file downloading slowly; however, I could be wrong. The code might need to download the whole file before interpeting it.

The way flash works, and the way this would work for video, is to specify a few formats that are acceptable, and to implement those in the browser. It's binary code. The only real overhead to playing video in flash are the controls that get added. Otherwise, it's just a binary video decoder throwing up pixels into a buffer. It's not like they'd implement the video decoding in Javascript too....

I'm not sure what to think. I love the idea of not needing to install Flash, but I also like being able to block annoying animations by not installing Flash.

I think overall, this isn't where things should head. It'd be much better if Flash were to simply work by exporting valid HTML5, CSS, and Javascript. Maybe there are some other advantages to the SWF format, but I'm not aware of them.

Presumably it would be trivial to block something well-specced (like video specific stuff in HTML5). Blocking flash blocks *all* flash, blocking video in HTML5 should be easier (no doubt an expert can chime in here and tell us both how easy it would be to ignore video in HTML5)

As an expert in ignoring things, I can vouch that it's easy to ignore things which you don't see. So my advice is to stop using the web and go outside more. That way you can ignore online advertisers, email and more! As for ignoring other people when you go outside, carry a bloody shovel over your shoulder and splash a little fresh blood on your clothes. Most people will go the other way.

Perhaps you wanted someone who was an expert in HTML5? I don't know those people, everyone seems to run away when they se

I'm not sure what to think. I love the idea of not needing to install Flash, but I also like being able to block annoying animations by not installing Flash.

And this is why we have things such as AdBlock (and variants) and NoScript. Presumably, if and when SVG and the HTML5 media tags start being used much more, there will be browser controls for whether the media should be run or ignored.

First of all, the main usage of Flash (for me) is video and I don't expect anyone to write h.232 codec using javascript and canvas anytime soon.

SVG has failed a long time ago. Correct me if I'm wrong, but there is no good way of putting it in the DOM unless you are using XHTML, which you shouldn't, and all other ways of getting it to the client are non-standard and handled differently by different browsers.

As someone rather new to flash, I'm not so sure how flash video works.

My assumption has always been that flash has support for h263 and other codecs coded into the plugin itself, so no one is writing flash actionscript to actually handle the codecs. If that's the case, the javascript flash implementation could likewise just pass the video decoding/rendering off to code in the browser designed to do that... unless I'm way off base, and people are actually writing actionscript for the video handling code, whi

The thing is, if the requirement is "Render a video at this coordinate on the page, with this size", the javascript implementation could simply go "Hey, pass that off as an and let another plugin handle it." Firefox's HTML5 code is being set up to handle an external supplier, for the linux case, gstreamer, in which case Firefox should be able to do html5 video with whatever codecs the system has available.

First of all, the main usage of Flash (for me) is video and I don't expect anyone to write h.232 codec using javascript and canvas anytime soon.

No, but if your browser supports the video tag and you have the correct codecs installed then something like this can implement the Flash video APIs in terms of that.

SVG has failed a long time ago. Correct me if I'm wrong, but there is no good way of putting it in the DOM unless you are using XHTML, which you shouldn't

You should use XHTML. Then you can mix HTML, MathML, and SVG in the same document, and have elements from all of them in the same DOM. The entire point of XHTML is to allow different XML formats to be used in the same document. Saying 'I want to do this without using the solution that was specifically designed for this exact problem' is a ve

How long before HTML5/SVG next-generation browsers [...] completely supplant Flash and Silverlight/Moonlight?"

I can't offer any informed opinion on that, but I can say that Flash and Silverlight/Moonlight will go down kicking and screaming. Much like the IE6 optimized websites that will continue to use them for many years to come.

I agree. Apple is just making life difficult for its users. Espectially because the iPhone doesn't multi-task that means if you wanted just use 100% cpu sure it will drain your battery faster but it is not like you are slowing down other apps.

Exactly! I have a major "WTF?" moment every time I see people opening PDFs in their web browser. Drives me nuts. And Mac people are all up in arms because Chrome on Mac doesn't (or didn't -- it may be implemented now) open PDFs in a plug-in. To me, that's a feature, not a bug.

I've never understood the logic of viewing PDF's inside the browser via plugin; I can understand it for flash or java, where they provide certain functionalities and integrate within the web page, but don't see why you'd want to use a PDF in-browser, which doesn't integrate with the rest of the site. Even worse is when the notoriously corpulent Acrobat plugin starts to load, your browser tends to either freeze (thanks IE6) or act like it's just snorted a gram of ketamine.

I've never understood the logic of viewing PDF's inside the browser via plugin; I can understand it for flash or java, where they provide certain functionalities and integrate within the web page, but don't see why you'd want to use a PDF in-browser, which doesn't integrate with the rest of the site.

It depends on the nature of the PDF. If it's a long windy document, then sure, I'll download it and read it separately. But, for example, a lot of C++0x papers are small (1-5 pages) PDFs, and when reading comp.std.c++, I have to view some random ones all the time. It doesn't make any sense to download them just for one view, and I never know when (and if) I'd need to view that one again. It's so much easier to just open the list [open-std.org], pick the paper I want, and have it open right there and then in the same windo

and Gnash started by implementing v1 before v2.. just like adobe did..
give the guy a break - what he did was not an easy feat (if it was it would have already been done).
why not give it some time or support - as far as i know Gnash isn't supported on an iPhone or many other devices.
he found a nich and filled it - and from what i saw - i don't think it would be too hard to update it and find flash objects via DOM and run Gordon in place of flash (if flash isn't available).. meaning after some updates m

...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 [gnashdev.org] 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.

Ah yes, another stab at (this is a killer!). Those predictions never pan out.
Specifically for this:
* All existing websites would need to be retrofitted to host.swf (.flv?) movies differently
* All popular browsers would need to embrace HTML5 video playback
* Microsoft would have to emphasize this over their own product.
* Adobe would have to emphasize this over their own product.
* The marketing department being utilized for this tech (at this time that would be 'no one') would have to be better funded and more highly motivated than both the Microsoft and Adobe marketing departments
* The vast majority of web users would have to care.
So, yeah, no.

* All existing websites would need to be retrofitted to host.swf (.flv?) movies differently

No, just enough of the big sites like Youtube. If a Flash replacement isn't advanced enough to do this it won't get widely used, but most people don't care about the little sites.

* All popular browsers would need to embrace HTML5 video playback *Microsoft would have to emphasize this over their own product. * Adobe would have to emphasize this over their own product.

uh... do you think Flash would magically disappear if a competitor arrives?

* The marketing department being utilized for this tech (at this time that would be 'no one') would have to be better funded and more highly motivated than both the Microsoft and Adobe marketing departments

If Firefox included it by default, it would be in almost 1/4 of all browsers globally. Sites will pay attention to that.

* The vast majority of web users would have to care.

No, they just have to use a modern Free browser that includes a reasonable Flash replacement.

Assuming this project gets far enough (and I doubt it will), there could easily be a Firefox plugin that imports this Javascript whenever it sees typical embedded Flash. Also, pandering to iPhone users who don't have a Flash plugin would bring this project into the mainstream almost over night.

According to the list of supported swf tags (http://wiki.github.com/tobeytailor/gordon/swf-tag-support-table ), it does not support DoABC, which means that it does not support Actionscript3. So basically, it only supports the parts of flash that really annoy people: Animations. This won't let you play many neat flash games, or replace Flex, or play a movie designed for Flash9 (introduced in 2006) or later.

As an Actionscript hobbyist, I love the idea of an open source implementation of the player. But so far, none of the open source alternatives support the features I actually like: Actionscript3. It's a strongly typed language with real classes, and it's compiled to bytecode rather than interpreted (mostly). Javascript has come a long way, but it still sucks if you like strongly typed variables.

Keep trying, Tobias. And if you get that byte-level access, let the world know.

I'm impressed! Flash has pretty much become an integral part of the web, yet you always had to download and install an extra plugin to be able to view flash content. Having an implementation of the flashplayer written in a language that can be executed by every major browser reguardless of the operating system is an incredibly useful thing to have.
And now with ever faster Processors and better implementations of JavaScript interpreters, I think its far from a bad thing to put more work into the hands of i

A giant jump for a project, a very small step for the web. Even if you catch current status of current web video players, Adobe/Microsoft will make sure that their solutions are the "right one", adding things, making developer switch to now "essential" shiny features, or even by deals with all the big video providers in the web. You know, like how the most popular browser used in the places where security matters isn't exactly the most secure one.

Sometimes the specific single letter has standardized usage, such as i and j, x and y, and so forth.

Then there are cases where the best name for a variable is something like 'value', 'string', 'data', 'array', or 'pointer' where using those instead of a single character doesnt help anybody.

Library programmers are more familiar with using single letters, because many variables are often entirely abstract and simply dont have a concrete meaning. What should you call the input to a sort function? 'arrayToB