I'm not sure if that says more about the poor optimization of the Mac Flash plugin or the great optimization of your browser's (Safari? Mac Chrome?) JS interpreter.
There's a lot more overhead to the plugin model, since the browser has to call to the plugin via NPAPI and the plugin has to draw itself separately, vs. just being integrated into the normal reflow/repaint of the webpage.
I was looking the other day for the webcam in the nearby village of, er, Flash. It took me a few seconds to realise why my searches for "Flash webcam" weren't finding it.
Of course it's damn impressive, but it doesn't seem very useful to me.
Nobody uses Flash for the language (actionscript is a terrible mash-up of javascript and Java, and haXe is not a lot better), or because we think the virtual machine is awesome in some way. Simply, we use it to bridge the gap between what web browsers can do and what native apps can do (access to webcams and microphones, local files, real tcp/ip sockets, etc, etc).
Having said all that, who knows - maybe web browsers really will eventually bridge those gaps themselves, and this will just be used to run legacy Flash code. It's possible I guess.
Wether flash stays dominant or not, this would still provide a way to run flash code without any proprietary plugin, and in any modern browser, so the interest is still big, from an user point of view
Compared to javascript, yes. True class-based inheritance, optional strict typing, getter setters, and methods and closures retain class scope. What's not to like? Null-reference errors?
While no one uses Flash for the language, there are a lot of (non-developers) out there who use Flash (MX,CS4 or whatever it's called this week) to produce animation, etc - and we're still a long way of having a similar set of tools that produce 'browser native' content.
Because a user is going to get the same experience already with the latest Flash player, in any browser. In JavaScript, there are numerous differences, ranging from the subtle to the not-so-subtle (do they even have canvas?) "Standards" aren't worth anything if they aren't, you know, standard.
I think you're actually agreeing with me here. I am saying that this project Gordon has appeal for folks that may want to do something like display a SWF in iPhone Safari.
> ranging from the subtle to the not-so-subtle (do they even have canvas?)
That's the beauty of this thing. It works with svg -> supported by all browsers (with the obvious exception of IE, although I think it shouldn't be too hard to change it to support VML).
Considering that the CPU usage on a Mac is lower than the Flash version of the same demo, that perhaps says a lot about the prospects of Flash on mobile devices . . .
That says nothing, considering this is coded up in an interpreted language (JS), compared to the speed of a compiled language (C/ObjC) on an official iPhone version of Flash, should there ever be one.
Languages aren't everything. Gnash, written in C++, never succeeded in replacing Flash even on platforms like *BSD where Flash was nonexistent.
In particular, when dealing with Flash, feature-completeness is going to be much more important than perfect performance. Since the Flash VM on Linux and OS X is so slow and software-renders everything, it really won't take much to improve on it. The advantages of a dynamic language are probably going to far outweigh C++'s speed, and Javascript's similarity to Actionscript is icing.
Plus, Javascript can take advantage of whatever hardware-accelerated graphics library the browser vendor chooses.
Also, I think most of the newer SWF files have lots of actionscript bytecode which is something that Gordon probably can't handle unless they implement their own stack-based virtual machine and implement all of the mx.core set of libraries.
A custom virtual machine probably isn't necessary. There are plenty of flash decompilers which can emit AS3 source from bytecode — and since ActionScript 3.0 is basically the old ECMAScript 6 draft spec, it can be trivially downcompiled to plain old Javascript using Mascara (http://ecmascript4.com/). Ideally the conversion would take place on a server-side proxy, and its ouput would subsequently be cached, but it could theoretically be done on the client as well. Re-implementing the standard library remains a major issue, but certainly not insurmountable.
That's the Flash Movie object, not H264 or Indeo video. A Flash Movie object is what Macromedia decided to call their hybrid format (like "page" for the Web, or "track" for audio).
It's a great new beginning, and a monumental effort on the part of one guy (the developer). Flash is undocumented (apart from what Adobe decided to share with search engine crawlers), and difficult to reverse-engineer.
This is not true at all. Flash is now an "open standard", in that Adobe released the specs to the file format, the VM, and most (all?) of the video format. For what it's worth, outside of a few errors in the documentation, it's fairly well written; I was working on a Flash->iPhone App compiler before Adobe announced theirs, and it was fairly straightforward to implement most things.
Does this actually implement the equivalent of Adobe's Flash runtime in Javascript? Does it work for all SWFs? If so, is there some sort of magic involved? If this works, how come things like Gnash and swfdec have never been able to achieve full compatability with Flash, yet this has seemingly come out of nowhere and done just that?
Cool technology to pursue but considering how Flash content's CPU requirements are often a problem on C-based interpreters, this doesn't seem like a practical thing.
When you see a pig dance it is impolite to comment on the quality of the dance, but you can express amazement at that it dances at all ;)
Let's give them a bit and see how far they take it. With a bit of luck they get some help from a nifty jit for js and who knows what might happen.
The evil .swf might turn in to a standard component after all, if only via a somewhat roundabout way.
I really wonder how they're going to do audio though, and capture devices and such are probably out (I can see a route to do video via the canvas, it's going to be bloody slow though unless js gets sped up a lot compared to where it is today).
Yes, I can't wait. I've been waiting for that literally for years.
Many years long we used a crappy old little javascript that I wrote long ago, it basically loads jpegs under water in to an off screen buffer and then flips them over the previous one when they're.
Using some trickery I could get pretty good framerates if the connection is good but the bandwidth cost is just terrible.
Now we've switched to (yuck) flash and it works ok I guess but something more standardized would be much appreciated.
It's translating to SVG, so there's "just" the script translation overhead, not rendering overhead. I think it's quite practical if maybe not especially useful given Flash penetration.
I wrote a Flash player for the PS2 ~9 years ago now that was fast enough. I'd say that current PCs + jitted JS are faster than that platform.
not really, if you're writing flash apps, there's a huge chance that you're actually writing as3 code, which gets compiled into DoABC tags (actionscript bytecode) and I don't think DoABC tags will ever be supported unless they implement a stack-based virtual machine in javascript.
It gives the appearance that it got cheaper to re-target, but really it will be a ton more work when you realize what will never be supported. Even if they managed to implement a virtual machine in javascript, they'd still need to implement all the library code that normally doesn't ship with every swf file.
http://github.com/tobeytailor/gordon/raw/master/demos/tiger....
Wish people made github pages a bit more friendly. It's like being thrown into a pit of 1s and 0s.