(Adobe) Flash Gordon!
January 13, 2010 4:41 PM Subscribe
Gordon is an open-source Flash runtime -- in JavaScript! Demos here and here. It only supports version 1 so far, but with hardware acceleration for things like <canvas> and SVG gaining traction, could have real potential. It even works on the iPhone. Only for Safari/WebKit, Firefox & Chrome. [via]
I know there's not a lot of info yet, but since plenty of MeFites work with these technologies, I figured it would be of interest.
I know there's not a lot of info yet, but since plenty of MeFites work with these technologies, I figured it would be of interest.
Site is timing out for me. Bah.
posted by potsmokinghippieoverlord at 4:52 PM on January 13, 2010
posted by potsmokinghippieoverlord at 4:52 PM on January 13, 2010
Can someone dumb this down? I work in tech and I don't know what this means. Admittedly, only on the third link, but I don't get what this gives me. Even did the demos. Why is this exciting or different than flash?
If these are dumb questions I was once in a bicycle accident and hit my head enough to black out.
posted by cjorgensen at 4:55 PM on January 13, 2010
If these are dumb questions I was once in a bicycle accident and hit my head enough to black out.
posted by cjorgensen at 4:55 PM on January 13, 2010
cjorgensen: "If these are dumb questions I was once in a bicycle accident and hit my head enough to black out."
If flash was a bicycle, and javascript was a unicycle, this would be riding a bicycle that is balanced on top of a unicycle.
posted by idiopath at 4:58 PM on January 13, 2010 [20 favorites]
If flash was a bicycle, and javascript was a unicycle, this would be riding a bicycle that is balanced on top of a unicycle.
posted by idiopath at 4:58 PM on January 13, 2010 [20 favorites]
Why is this exciting or different than flash?
This is something that runs Flash apps, but it doesn't use the Flash plugin, instead it is written in Javascript and runs natively in the browser.
posted by Jimbob at 4:59 PM on January 13, 2010 [2 favorites]
This is something that runs Flash apps, but it doesn't use the Flash plugin, instead it is written in Javascript and runs natively in the browser.
posted by Jimbob at 4:59 PM on January 13, 2010 [2 favorites]
And I've been having problems with Flash's latest plugins, enough so that I've started rooting for Silverlight in my black little heart.
posted by boo_radley at 5:01 PM on January 13, 2010
posted by boo_radley at 5:01 PM on January 13, 2010
So @paul_irish did was Adobe couldn't?
And seriously, I read Daring Fireball every day, but didn't have time yet today. You would think if this is what I think it is that Gruber would have given more context or someone might have linked to a tech article explaining how they are riding a bicycle that is balanced on top of a unicycle.
I want to know how. I miss this part?
posted by cjorgensen at 5:03 PM on January 13, 2010
And seriously, I read Daring Fireball every day, but didn't have time yet today. You would think if this is what I think it is that Gruber would have given more context or someone might have linked to a tech article explaining how they are riding a bicycle that is balanced on top of a unicycle.
I want to know how. I miss this part?
posted by cjorgensen at 5:03 PM on January 13, 2010
So that there's some non plugin alternative, is great news.
Is what the gist of what I deleted said. God, I'm going home.
posted by boo_radley at 5:03 PM on January 13, 2010
Is what the gist of what I deleted said. God, I'm going home.
posted by boo_radley at 5:03 PM on January 13, 2010
My reactions, in order:
1) OMGWAT
2) Of course, the "regular" open-source Flash player barely works, how much less functional is a javascript implementation going to be?
3) That said, the closed-source Flash player doesn't work much better than that either (on 64 bit Linux especially) so...
posted by DU at 5:03 PM on January 13, 2010
1) OMGWAT
2) Of course, the "regular" open-source Flash player barely works, how much less functional is a javascript implementation going to be?
3) That said, the closed-source Flash player doesn't work much better than that either (on 64 bit Linux especially) so...
posted by DU at 5:03 PM on January 13, 2010
This is very cool, though I predict in addition to sound issues that neustile points out, there are going to be performance issues with certain javascript engines.
Though a thorough implementation of HTML5 may make it completely possible... I don't know enough details about the problems they face to say for sure. It would be nice to have Flash support in non-Linux 64bit processes, so even without sound I welcome it.
posted by jeffamaphone at 5:05 PM on January 13, 2010
Though a thorough implementation of HTML5 may make it completely possible... I don't know enough details about the problems they face to say for sure. It would be nice to have Flash support in non-Linux 64bit processes, so even without sound I welcome it.
posted by jeffamaphone at 5:05 PM on January 13, 2010
the sound stuff is going to stop them cold, there is still no good PCM synth (or even reliable timing sample playback) on the web w/o flash.
We're getting there.
posted by scottreynen at 5:27 PM on January 13, 2010 [2 favorites]
We're getting there.
posted by scottreynen at 5:27 PM on January 13, 2010 [2 favorites]
As a day to day thing, would never actually interpret flash byte code in (uncompiled) javascript. This is more a proof of concept, hey look what can be done type project.
If I had to guess the "point" of this:
1. a not too subtle counterproof for those convinced that html5 and javascript are lesser than the current crop of declarative rich interface tools. (Well, of course everyone knows they are still lesser *now*, but this shows how far things have come)
2. someone's cool project to show how much of balls out hacker they are.
I believe he succeeded on both points.
posted by PissOnYourParade at 5:29 PM on January 13, 2010 [3 favorites]
If I had to guess the "point" of this:
1. a not too subtle counterproof for those convinced that html5 and javascript are lesser than the current crop of declarative rich interface tools. (Well, of course everyone knows they are still lesser *now*, but this shows how far things have come)
2. someone's cool project to show how much of balls out hacker they are.
I believe he succeeded on both points.
posted by PissOnYourParade at 5:29 PM on January 13, 2010 [3 favorites]
An attempt at explaining it for non-techies:
Most people in the US speak English. In recent years, China - inhabited, for the sake of this metaphor, by people who speak a single Chinese language - has become a huge market. But the Chinese government refuses to allow English documents into the country, because they believe that English is a crash-prone battery-sucking piece of oh sorry losing the metaphor.
Anyway, only Chinese is allowed into China. But all these English-speaking Americans want to be able to talk to the Chinese to make money. This is the equivalent of an automatic English-to-Chinese translator that allows you to say "Hello!" and see "Ni Hao!" come out the other end. As an automatic translator, it will probably occasionally come up with "I am pleased to eat your children, Mr. Vice President," but it's still a pretty huge deal that it exists and you A) don't have to necessarily learn Chinese (though your prose will probably be tons better if you do) and B) you can easily introduce Chinese speakers to all your existing awesome English-language things like Harry Potter and the Hidden Penthouse From 1983.
posted by Tomorrowful at 5:29 PM on January 13, 2010 [2 favorites]
Most people in the US speak English. In recent years, China - inhabited, for the sake of this metaphor, by people who speak a single Chinese language - has become a huge market. But the Chinese government refuses to allow English documents into the country, because they believe that English is a crash-prone battery-sucking piece of oh sorry losing the metaphor.
Anyway, only Chinese is allowed into China. But all these English-speaking Americans want to be able to talk to the Chinese to make money. This is the equivalent of an automatic English-to-Chinese translator that allows you to say "Hello!" and see "Ni Hao!" come out the other end. As an automatic translator, it will probably occasionally come up with "I am pleased to eat your children, Mr. Vice President," but it's still a pretty huge deal that it exists and you A) don't have to necessarily learn Chinese (though your prose will probably be tons better if you do) and B) you can easily introduce Chinese speakers to all your existing awesome English-language things like Harry Potter and the Hidden Penthouse From 1983.
posted by Tomorrowful at 5:29 PM on January 13, 2010 [2 favorites]
Er, for what it's worth, above, I'm casting Apple as the Chinese government, China as iPhone users, and Americans as the vast number of Flash developers out there. Obviously there are applications for this other than just running stuff on the iPhone, but Apple's dogged refusal to introduce Flash to the iPhone is a pretty big problem for the Flash platform as Apple's share of web-viewing gadgets takes off.
posted by Tomorrowful at 5:31 PM on January 13, 2010
posted by Tomorrowful at 5:31 PM on January 13, 2010
That is one crazy metaphor.
posted by jeffamaphone at 5:32 PM on January 13, 2010
posted by jeffamaphone at 5:32 PM on January 13, 2010
Google Closure uses that tiger too ... is there some sort of tiger in joke I missed?
posted by geoff. at 5:49 PM on January 13, 2010
posted by geoff. at 5:49 PM on January 13, 2010
I was going to post the exact same question as geoff. did. I wonder if it's inspired by Closure in any way? Poking around the source code didn't reveal any obvious direct dependencies.
Regardless, this is completely awesome.
posted by kdar at 5:54 PM on January 13, 2010
Regardless, this is completely awesome.
posted by kdar at 5:54 PM on January 13, 2010
But yeah, Javascript is eating up legacy systems one emulator at a time:
6502 assembler
ZX Spectrum
Applesoft BASIC
Amiga
Commodore 64
Gameboy
NES
Processing
posted by gwint at 6:13 PM on January 13, 2010 [4 favorites]
6502 assembler
ZX Spectrum
Applesoft BASIC
Amiga
Commodore 64
Gameboy
NES
Processing
posted by gwint at 6:13 PM on January 13, 2010 [4 favorites]
I believe the tiger is an old SVG example.
It was a Postscript example before migrating to SVG. With the Utah Teapot and Lenna it forms part of the Holy Trinity of test images.
posted by monocyte at 6:23 PM on January 13, 2010 [4 favorites]
It was a Postscript example before migrating to SVG. With the Utah Teapot and Lenna it forms part of the Holy Trinity of test images.
posted by monocyte at 6:23 PM on January 13, 2010 [4 favorites]
The tiger is older than SVG - I remember seeing it as an early demonstration of Color PostScript, probably in the early 90's. I want to say it was created in Corel Draw! but I couldn't swear to it.
posted by kcds at 6:34 PM on January 13, 2010
posted by kcds at 6:34 PM on January 13, 2010
Apple's dogged refusal to introduce Flash to the iPhone is a pretty big problem for the Flash platform
Not on Android either, for the most part. Only specific implementations on a (very) few Android-based phones separate from the actual Android OS. (At least last time I looked.)
posted by inigo2 at 7:17 PM on January 13, 2010
Not on Android either, for the most part. Only specific implementations on a (very) few Android-based phones separate from the actual Android OS. (At least last time I looked.)
posted by inigo2 at 7:17 PM on January 13, 2010
I think other people took a stab at explaining this but the basic takeaway is that, or order to run flash, you need a plugin. Almost everyone has the plug in on their desktops already, so it's not that big of a deal.
But, with the iPhone and other cellphones coming out, they don't run flash. But they do run Javascript. So, if you can run flash in javascript, then you don't need the plug in. Plus, like PissOnYourParade said, whoever wrote this instantly earned the respect of people who do understand this. It's pretty amazing.
Anyway, for those who don't know what the <canvas> tag is, it's just an HTML tag that defines a region on the page, like a DIV or whatever else. What's special about it though is that you can use javascript to draw on it. That means you can display any image you want, and change the image however you please (if you can figure out the coding).
So, you can write a Javascript engine that runs flash. Or whatever you want. Someone even wrote this DOOM style game in javascript. (I swear someone actually ported real DOOM to JS)
So basically this frees flash from requiring a plug in. But it's also a proof of concept that shows that you can do all the cool, propritary-plug-in stuff using just plain HTML. It means everything on the web can be done using just the open source stuff that's available.
posted by delmoi at 7:35 PM on January 13, 2010 [3 favorites]
But, with the iPhone and other cellphones coming out, they don't run flash. But they do run Javascript. So, if you can run flash in javascript, then you don't need the plug in. Plus, like PissOnYourParade said, whoever wrote this instantly earned the respect of people who do understand this. It's pretty amazing.
Anyway, for those who don't know what the <canvas> tag is, it's just an HTML tag that defines a region on the page, like a DIV or whatever else. What's special about it though is that you can use javascript to draw on it. That means you can display any image you want, and change the image however you please (if you can figure out the coding).
So, you can write a Javascript engine that runs flash. Or whatever you want. Someone even wrote this DOOM style game in javascript. (I swear someone actually ported real DOOM to JS)
So basically this frees flash from requiring a plug in. But it's also a proof of concept that shows that you can do all the cool, propritary-plug-in stuff using just plain HTML. It means everything on the web can be done using just the open source stuff that's available.
posted by delmoi at 7:35 PM on January 13, 2010 [3 favorites]
Ok, what are the security implications of this, if any?
posted by Brandon Blatcher at 8:10 PM on January 13, 2010
posted by Brandon Blatcher at 8:10 PM on January 13, 2010
Also, correct me if I'm wrong, but the problem with Flash on the iPhone (and the Mac in general) is that it's a resource huge, sucking up processing cycles and battery power like crazy. Does this implementation avoid that?
posted by Brandon Blatcher at 8:15 PM on January 13, 2010
posted by Brandon Blatcher at 8:15 PM on January 13, 2010
Also, for those unfamiliar but curious about the canvas tag, here's a tutorial.
posted by Brandon Blatcher at 8:18 PM on January 13, 2010
posted by Brandon Blatcher at 8:18 PM on January 13, 2010
Brandon Blatcher: "Also, correct me if I'm wrong, but the problem with Flash on the iPhone (and the Mac in general) is that it's a resource huge, sucking up processing cycles and battery power like crazy. Does this implementation avoid that?"
I am 100% certain it will be worse. The point of my bicycle on top of a unicycle analogy is that the javascript engine is already very abstracted from the hardware (and inefficient because of that) and with that baseline this way of implementing flash is a silly use of resources if that scale of resources is in any way an issue.
posted by idiopath at 8:21 PM on January 13, 2010
I am 100% certain it will be worse. The point of my bicycle on top of a unicycle analogy is that the javascript engine is already very abstracted from the hardware (and inefficient because of that) and with that baseline this way of implementing flash is a silly use of resources if that scale of resources is in any way an issue.
posted by idiopath at 8:21 PM on January 13, 2010
idiopath, i'm not sure why it would be worse. Just to load flash takes additional ram, drive space, and cpu cycles. You need to take that into account.
posted by empath at 8:58 PM on January 13, 2010
posted by empath at 8:58 PM on January 13, 2010
I am willing to bet that implementing flash 10 in javascript would take up much more ram than the binary for flash10, at least at runtime. Even given that they are both technically implementations of ecmascript.
Emulating flash in javascript is a layer of indirection, as compared to the flash plugin that directly runs as a binary. You cannot get closer to the metal than your platform, and as a platform javascript is very far from the metal.
posted by idiopath at 9:03 PM on January 13, 2010
Emulating flash in javascript is a layer of indirection, as compared to the flash plugin that directly runs as a binary. You cannot get closer to the metal than your platform, and as a platform javascript is very far from the metal.
posted by idiopath at 9:03 PM on January 13, 2010
Even given that they are both technically implementations of ecmascript.
Well, yeah, but I don't think they're even implementations of the same version of ECMAscript. ActionScript 3 is a strongly-typed, class-based OO language, and that change from the loose typing and prototype base of AS2 appears to be responsible for a HUGE performance difference. JavaScript in the browser has not yet gotten that kind of performance enhancement, as far as I know - please correct me if I'm wrong about that!
posted by me & my monkey at 9:20 PM on January 13, 2010
Well, yeah, but I don't think they're even implementations of the same version of ECMAscript. ActionScript 3 is a strongly-typed, class-based OO language, and that change from the loose typing and prototype base of AS2 appears to be responsible for a HUGE performance difference. JavaScript in the browser has not yet gotten that kind of performance enhancement, as far as I know - please correct me if I'm wrong about that!
posted by me & my monkey at 9:20 PM on January 13, 2010
Ok, what are the security implications of this, if any?
I can't think of any. You're running the browser's JavaScript environment, which, theoretically, already has security in place. So there would have to be bugs in both the JavaScript/Browser layer and the Flash emulator written in JavaScript. If anything, it's more secure, since Flash is a native plug-in and can bypass the browser security model.
Does this implementation avoid that?
I doubt that this will ever be faster than the native Flash runtime.
posted by jeffamaphone at 9:38 PM on January 13, 2010
I can't think of any. You're running the browser's JavaScript environment, which, theoretically, already has security in place. So there would have to be bugs in both the JavaScript/Browser layer and the Flash emulator written in JavaScript. If anything, it's more secure, since Flash is a native plug-in and can bypass the browser security model.
Does this implementation avoid that?
I doubt that this will ever be faster than the native Flash runtime.
posted by jeffamaphone at 9:38 PM on January 13, 2010
Idiopath is entirely correct, this thing is using 40% of my CPU just rendering a static graphic - in order to get flash working on a low power device like an iPhone the player needs to very efficient and compiled natively.
Even then, authors of flash content would need to optimise for it. Does your banner have a few images fading in at once? Fail. Do you load a 200kb XML file and immediately trawl through it recursively? Fail.
The last couple of player versions have actually been pretty good, performance-wise - unfortunately this just makes people think they can push it harder. Actually, unless you've got a very high-end desktop machine, even now you probably only see Flash content running at some fraction of the speed it was intended to go at due to clueless designers and developers.
That's why you'll never have a phone type device that displays most Flash content the way you see it on your laptop.
On preview: Yeah, AS3 should be (and in my experience, is) quicker than JS due to the static typing and stuff. However, I think Tamarin (Adobe open-sourced AVM2) should be in Spidermonkey (hence Firefox) by now so there may be little difference in practice. My knowledge runs out around here.
posted by dickasso at 9:38 PM on January 13, 2010
Even then, authors of flash content would need to optimise for it. Does your banner have a few images fading in at once? Fail. Do you load a 200kb XML file and immediately trawl through it recursively? Fail.
The last couple of player versions have actually been pretty good, performance-wise - unfortunately this just makes people think they can push it harder. Actually, unless you've got a very high-end desktop machine, even now you probably only see Flash content running at some fraction of the speed it was intended to go at due to clueless designers and developers.
That's why you'll never have a phone type device that displays most Flash content the way you see it on your laptop.
On preview: Yeah, AS3 should be (and in my experience, is) quicker than JS due to the static typing and stuff. However, I think Tamarin (Adobe open-sourced AVM2) should be in Spidermonkey (hence Firefox) by now so there may be little difference in practice. My knowledge runs out around here.
posted by dickasso at 9:38 PM on January 13, 2010
Maybe I missed where this is addressed, but what throws me the most about this is that I always thought .SWF was a binary format, which means that somehow they are parsing it? That is what confuses me here.
posted by feloniousmonk at 10:50 PM on January 13, 2010
posted by feloniousmonk at 10:50 PM on January 13, 2010
Yeah it is a bytecode format, but adobe is open about the spec so parsing it is no big mystery.
posted by idiopath at 10:53 PM on January 13, 2010
posted by idiopath at 10:53 PM on January 13, 2010
I am willing to bet that implementing flash 10 in javascript would take up much more ram than the binary for flash10, at least at runtime. Even given that they are both technically implementations of ecmascript.
I think I misunderstood what this was doing, then. I thought this was automatically translating SWF files into a javascript equivalent, but I guess what it is really doing is implementing a replacement for the flash plug-in in javascript and then loading the SWF file the same way that flash would?
posted by empath at 11:11 PM on January 13, 2010
I think I misunderstood what this was doing, then. I thought this was automatically translating SWF files into a javascript equivalent, but I guess what it is really doing is implementing a replacement for the flash plug-in in javascript and then loading the SWF file the same way that flash would?
posted by empath at 11:11 PM on January 13, 2010
empath: "thought this was automatically translating SWF files into a javascript equivalent, but I guess what it is really doing is implementing a replacement for the flash plug-in in javascript and then loading the SWF file the same way that flash would?"
To-may-to To-mah-to - they sound different in English, but programming it comes down to exactly the same task. In terms of the computations that must be performaed, a program that translates a program from language A to language B and then executes it is exactly the same thing as an interpreter for language A written in language B, unless the behavior of language A explicitly specifies low level behaviors like stack usage or register allocation (not a concern with ecmascript based languages, I assure you).
posted by idiopath at 11:23 PM on January 13, 2010
To-may-to To-mah-to - they sound different in English, but programming it comes down to exactly the same task. In terms of the computations that must be performaed, a program that translates a program from language A to language B and then executes it is exactly the same thing as an interpreter for language A written in language B, unless the behavior of language A explicitly specifies low level behaviors like stack usage or register allocation (not a concern with ecmascript based languages, I assure you).
posted by idiopath at 11:23 PM on January 13, 2010
Right, but the difference to me is that I thought that the demos were swf files that had been pretranslated (so that the finished product wouldn't take any more resources than normal javascript), not that they were being loaded and translated at run time by an implementation of flash in javascript (which would obviously use a ton of RAM and cpu)
posted by empath at 11:34 PM on January 13, 2010
posted by empath at 11:34 PM on January 13, 2010
> Apple's dogged refusal to introduce Flash to the iPhone is a pretty big problem for the Flash platform as Apple's share of web-viewing gadgets takes off.
There are no phones running a full-fledged version of Flash, to the best of my knowledge. Even though Adobe has been promising Flash 10 for a while, neither phone hardware nor OS manufacturers have been eager to offer it.
Flash Lite is available, but you probably can't find a phone with it installed unless you're in Japan and looking for a flip phone.
posted by ardgedee at 6:19 AM on January 14, 2010
There are no phones running a full-fledged version of Flash, to the best of my knowledge. Even though Adobe has been promising Flash 10 for a while, neither phone hardware nor OS manufacturers have been eager to offer it.
Flash Lite is available, but you probably can't find a phone with it installed unless you're in Japan and looking for a flip phone.
posted by ardgedee at 6:19 AM on January 14, 2010
Wow. That is... completely and utterly insane. On my fairly newish Mac at work, it loads those examples in a snap, and (I shit you not) I'm certain that the same examples would lock it up for a good 30 seconds each with the normal Flash player.
posted by kryptondog at 6:41 AM on January 14, 2010
posted by kryptondog at 6:41 AM on January 14, 2010
He *did* save every one of us, after all.
posted by Civil_Disobedient at 6:50 AM on January 14, 2010 [1 favorite]
posted by Civil_Disobedient at 6:50 AM on January 14, 2010 [1 favorite]
empath: "I thought that the demos were swf files that had been pretranslated"
I see no claims of pretranslation in any of the links (I have not having read the source yet, will look into that soon if none of the documentation clarifies the issue). And if you want to replace the existing flash, I assure you that one of the primary reasons it is used is the fact that the source code is not being transmitted. People like to pretend that compiling into the .swf means that their program is now hidden from competitors. Yeah you can obfuscate any language including javascript but nothing can hide the algorithm from an educated, patient, and curious person.
Anyway pretranslation is just partial compilation, which flash is already doing by creating the .swf, but by using another language for which the .swf is not a partial compilation, you are now two steps behind, you have to decompile and then recompile (ie. create the intermediate code based on the bytecode, and then turn that back into the contents of ram neccessary for running, even in an interpreted language - and since javascript does not use any sort of intermediate code that I know of in any existing implementation, they need to turn the swf bytecode into text and then parse the text it just generated, before doing the other steps).
Every new programming language is implemented in another language (except for things like forth where people actually have reason to implement in machine code or assembler macros - even C is developed almost entirely using the previous version of the existing C compiler). The problem is that javascript is a really bad choice of a target language if your goal is improving on the performance of flash. The other problem is that automated translations between languages tend to cause big performance hits, unless done by a skilled compiler writer as a long term project. You could maybe try java, but even that would have some issues. And most other options would have platform dependence issues.
On the other hand, put a good cross platform vector graphics rendering engine on top of the bytecode version of OCaml and you could probably give flash a run for the money, even if you were translating the flash bytecode instead of using a native format. Based on my experience the only thing holding OCaml back from mainstream success is the fact that they are not using algol family (AKA "C like") syntax (me, I like the ML family syntax better than algol anyway, but most programmers are too lazy to learn more than one syntax family in a lifetime).
posted by idiopath at 7:40 AM on January 14, 2010
I see no claims of pretranslation in any of the links (I have not having read the source yet, will look into that soon if none of the documentation clarifies the issue). And if you want to replace the existing flash, I assure you that one of the primary reasons it is used is the fact that the source code is not being transmitted. People like to pretend that compiling into the .swf means that their program is now hidden from competitors. Yeah you can obfuscate any language including javascript but nothing can hide the algorithm from an educated, patient, and curious person.
Anyway pretranslation is just partial compilation, which flash is already doing by creating the .swf, but by using another language for which the .swf is not a partial compilation, you are now two steps behind, you have to decompile and then recompile (ie. create the intermediate code based on the bytecode, and then turn that back into the contents of ram neccessary for running, even in an interpreted language - and since javascript does not use any sort of intermediate code that I know of in any existing implementation, they need to turn the swf bytecode into text and then parse the text it just generated, before doing the other steps).
Every new programming language is implemented in another language (except for things like forth where people actually have reason to implement in machine code or assembler macros - even C is developed almost entirely using the previous version of the existing C compiler). The problem is that javascript is a really bad choice of a target language if your goal is improving on the performance of flash. The other problem is that automated translations between languages tend to cause big performance hits, unless done by a skilled compiler writer as a long term project. You could maybe try java, but even that would have some issues. And most other options would have platform dependence issues.
On the other hand, put a good cross platform vector graphics rendering engine on top of the bytecode version of OCaml and you could probably give flash a run for the money, even if you were translating the flash bytecode instead of using a native format. Based on my experience the only thing holding OCaml back from mainstream success is the fact that they are not using algol family (AKA "C like") syntax (me, I like the ML family syntax better than algol anyway, but most programmers are too lazy to learn more than one syntax family in a lifetime).
posted by idiopath at 7:40 AM on January 14, 2010
idiopath: "will look into that soon if none of the documentation clarifies the issue"
This is their flash bytecode interpretation table (from the file _base.js); they are definitely reading flash bytecode, generating javascript text, and then interpreting that text:
_g.tagCodes = {
END: 0,
SHOW_FRAME: 1,
DEFINE_SHAPE: 2,
PLACE_OBJECT: 4,
REMOVE_OBJECT: 5,
DEFINE_BITS: 6,
DEFINE_BUTTON: 7,
JPEG_TABLES: 8,
SET_BACKGROUND_COLOR: 9,
DEFINE_FONT: 10,
DEFINE_TEXT: 11,
DO_ACTION: 12,
DEFINE_FONT_INFO: 13,
DEFINE_SOUND: 14,
START_SOUND: 15,
DEFINE_BUTTON_SOUND: 17,
SOUND_STREAM_HEAD: 18,
SOUND_STREAM_BLOCK: 19,
DEFINE_BITS_LOSSLESS: 20,
DEFINE_BITS_JPEG2: 21,
DEFINE_SHAPE2: 22,
DEFINE_BUTTON_CXFORM: 23,
PROTECT: 24,
PLACE_OBJECT2: 26,
REMOVE_OBJECT2: 28,
DEFINE_SHAPE3: 32,
DEFINE_TEXT2: 33,
DEFINE_BUTTON2: 34,
DEFINE_BITS_JPEG3: 35,
DEFINE_BITS_LOSSLESS2: 36,
DEFINE_EDIT_TEXT: 37,
DEFINE_SPRITE: 39,
FRAME_LABEL: 43,
SOUND_STREAM_HEAD2: 45,
DEFINE_MORPH_SHAPE: 46,
DEFINE_FONT2: 48,
EXPORT_ASSETS: 56,
IMPORT_ASSETS: 57,
ENABLE_DEBUGGER: 58,
DO_INIT_ACTION: 59,
DEFINE_VIDEO_STREAM: 60,
VIDEO_FRAME: 61,
DEFINE_FONT_INFO2: 62,
ENABLE_DEBUGGER2: 64,
SCRIPT_LIMITS: 65,
SET_TAB_INDEX: 66,
FILE_ATTRIBUTES: 69,
PLACE_OBJECT3: 70,
IMPORT_ASSETS2: 71,
DEFINE_FONT_ALIGN_ZONES: 73,
CSM_TEXT_SETTINGS: 74,
DEFINE_FONT3: 75,
SYMBOL_CLASS: 76,
METADATA: 77,
DEFINE_SCALING_GRID: 78,
DO_ABC: 82,
DEFINE_SHAPE4: 83,
DEFINE_MORPH_SHAPE2: 84,
DEFINE_SCENE_AND_FRAME_LABEL_DATA: 86,
DEFINE_BINARY_DATA: 87,
DEFINE_FONT_NAME: 88,
START_SOUND2: 89,
DEFINE_BITS_JPEG4: 90,
DEFINE_FONT4: 91
};
posted by idiopath at 7:53 AM on January 14, 2010
I don't think anyone is imagining this will be an attractive way to play flash in the browser.
What's interesting here is that if javascript can play flash, even badly, it drives home the point that developers can deliver video and games to users in the browser without flash. Flash isn't going anywhere anytime soon, but this at least undermines arguments of its inevitability.
(One downside to this taking off: flashblock would eventually cease to be such an effective means of stopping annoying stuff.)
posted by Zed at 10:34 AM on January 14, 2010
What's interesting here is that if javascript can play flash, even badly, it drives home the point that developers can deliver video and games to users in the browser without flash. Flash isn't going anywhere anytime soon, but this at least undermines arguments of its inevitability.
(One downside to this taking off: flashblock would eventually cease to be such an effective means of stopping annoying stuff.)
posted by Zed at 10:34 AM on January 14, 2010
Nifty, but doomed to remain a toy.
The problem with this project (and most others like it) is that the pure "tag-based flash SWF" is pretty much a dinosaur. It's pretty much par for the course these days to just "stop()" on the first frame and then use Actionscript-based event handlers to trigger everything.
Looking at their support table:
59 DoInitAction 6 no
This is the tag that tied Actionscript classes to visual objects. Without Actionscript, you're doomed. Maybe you can display Viking Kittens or YTMD or Strongbad or something, but anything beyond that era, forget it. Even if they implemented DoInitAction and an AS2 bytecode interpreter, that only puts them up to Flash Player 8. (I see DoAction as a "yes", which confuses me.)
In any case, for Flash Player 9+, the language switched to AS3 (ECMAScript 4), with an entirely new compiler and an entirely new JIT-oriented virtual machine. The current Flash player has both the old AS2 VM and the AS3 VM embedded. Lacking the Actionscript Bytecode tag:
2 DoABC 9 no
you don't get to run any modern Flash apps. End of story. Oh, and parsing and correctly executing a DoABC tag is about a zillion times more difficult than the old DoInitAction tag. Security sandboxes, code resolution, core API calls... then you get to the efficiency battle, where Adobe's code is not actually interpreting the bytecode, but actually validating it and JITting native instructions, per-architecture.
Now, the Tamarin project is about embedding a lot of this new Adobe VM into Mozilla projects. (This leaves every other browser incompatible, of course.) Even for Firefox I have zero expectation that the the bytecode chunks will be compatible (and it would surprise me if bytecode execution was exposed to user code). Just to support this single browser, it would still minimally require a "parse DoABC and emit altered bytecode" step. I don't know much about Tamarin, but I'm pretty certain this would be... hard if not impossible. A generic approach (with all the resulting performance issues) seems more likely to me.
Let me put it this way; I wrote a lot of the code that imports Flash v1-8 SWF files to use as embedded media assets in Flex-based AS3 SWF applications. I considered porting over "simple" AS2 bytecode that wouldn't require emulating old-VM Flash API calls in the new VM, but the more I investigated, the more I decided it wasn't worth it. (It turned out that this wasn't even a big requirement anyway. There aren't that many people that want to embed old Flash SWFs, because if they want to embed SWFs, they probably can just export a modern v9+ SWC library of their assets and link it in.)
Even if you surmount all the hurdles I've mentioned, the difficulty in building your own Flash player has little to do with parsing the SWF or even executing bytecode, it's accurately emulating the (complex) player APIs as well as the behavioral quirks of the player for each SWF version you want to support. The whole benefit (and curse) of Flash is that it provides a (by-comparison to DHTML) (self-)consistent cross-platform VM, with versioning explicit in the header. No Flash developer in their right mind is ever going to try supporting the additional quirks of various feature-poor and performance-lagging open SWF players, which means that 99.9% of all users that use Flash are just going to stick to Adobe's player.
I honestly think that a clean-slate open rich media player would be a much better approach than trying to rebuild Flash.
posted by argh at 2:18 PM on January 14, 2010 [2 favorites]
The problem with this project (and most others like it) is that the pure "tag-based flash SWF" is pretty much a dinosaur. It's pretty much par for the course these days to just "stop()" on the first frame and then use Actionscript-based event handlers to trigger everything.
Looking at their support table:
59 DoInitAction 6 no
This is the tag that tied Actionscript classes to visual objects. Without Actionscript, you're doomed. Maybe you can display Viking Kittens or YTMD or Strongbad or something, but anything beyond that era, forget it. Even if they implemented DoInitAction and an AS2 bytecode interpreter, that only puts them up to Flash Player 8. (I see DoAction as a "yes", which confuses me.)
In any case, for Flash Player 9+, the language switched to AS3 (ECMAScript 4), with an entirely new compiler and an entirely new JIT-oriented virtual machine. The current Flash player has both the old AS2 VM and the AS3 VM embedded. Lacking the Actionscript Bytecode tag:
2 DoABC 9 no
you don't get to run any modern Flash apps. End of story. Oh, and parsing and correctly executing a DoABC tag is about a zillion times more difficult than the old DoInitAction tag. Security sandboxes, code resolution, core API calls... then you get to the efficiency battle, where Adobe's code is not actually interpreting the bytecode, but actually validating it and JITting native instructions, per-architecture.
Now, the Tamarin project is about embedding a lot of this new Adobe VM into Mozilla projects. (This leaves every other browser incompatible, of course.) Even for Firefox I have zero expectation that the the bytecode chunks will be compatible (and it would surprise me if bytecode execution was exposed to user code). Just to support this single browser, it would still minimally require a "parse DoABC and emit altered bytecode" step. I don't know much about Tamarin, but I'm pretty certain this would be... hard if not impossible. A generic approach (with all the resulting performance issues) seems more likely to me.
Let me put it this way; I wrote a lot of the code that imports Flash v1-8 SWF files to use as embedded media assets in Flex-based AS3 SWF applications. I considered porting over "simple" AS2 bytecode that wouldn't require emulating old-VM Flash API calls in the new VM, but the more I investigated, the more I decided it wasn't worth it. (It turned out that this wasn't even a big requirement anyway. There aren't that many people that want to embed old Flash SWFs, because if they want to embed SWFs, they probably can just export a modern v9+ SWC library of their assets and link it in.)
Even if you surmount all the hurdles I've mentioned, the difficulty in building your own Flash player has little to do with parsing the SWF or even executing bytecode, it's accurately emulating the (complex) player APIs as well as the behavioral quirks of the player for each SWF version you want to support. The whole benefit (and curse) of Flash is that it provides a (by-comparison to DHTML) (self-)consistent cross-platform VM, with versioning explicit in the header. No Flash developer in their right mind is ever going to try supporting the additional quirks of various feature-poor and performance-lagging open SWF players, which means that 99.9% of all users that use Flash are just going to stick to Adobe's player.
I honestly think that a clean-slate open rich media player would be a much better approach than trying to rebuild Flash.
posted by argh at 2:18 PM on January 14, 2010 [2 favorites]
There was some mention of canvas up above, this library is actually using SVG. This is a bit more interesting than hypothetically being able to play flash movies on an IPhone - as others have pointed out this is never going to be an efficient way of doing that - what it does demonstrate is that there's nothing Flash does in the vector graphics department than can't be done right now (in modern browsers) with SVG. There's still all that streaming video and audio malarkey, but we have different HTML5 elements for that ;)
posted by robertc at 2:43 PM on January 14, 2010
posted by robertc at 2:43 PM on January 14, 2010
Argh: would it be impossible to interpret/translate AS into JS?
posted by alex.dudley at 3:49 PM on January 14, 2010
posted by alex.dudley at 3:49 PM on January 14, 2010
They are both Turing complete, so it is by definition possible. His point is that it would also be a waste of time.
posted by idiopath at 4:16 PM on January 14, 2010
posted by idiopath at 4:16 PM on January 14, 2010
They are both Turing complete, so it is by definition possible.
C and the SJK combinator calculus are both Turing complete, but I'd like to see you translate this C program into the combinator calculus:
int main(int ac, char** av) {
printf("Hello, World\n");
return 0;
}
posted by kenko at 8:32 PM on January 14, 2010
C and the SJK combinator calculus are both Turing complete, but I'd like to see you translate this C program into the combinator calculus:
int main(int ac, char** av) {
printf("Hello, World\n");
return 0;
}
posted by kenko at 8:32 PM on January 14, 2010
Presuming that adding an output library to the combinator calculus is allowed, the folks who did unlambda were kind enough to provide a translation for me, that is pretty darn close:
Otherwise, of course, it is impossible. Point taken, I should have said something more like "since they are both Turing complete and capable of displaying and manipulating bitmaps and reading and writing network data, all non audio, non webcam, and non disk usage related functionality would be possible, but it would be a waste of time".
posted by idiopath at 10:19 PM on January 14, 2010
`r```````````.H.e.l.l.o. .W.o.r.l.di
Otherwise, of course, it is impossible. Point taken, I should have said something more like "since they are both Turing complete and capable of displaying and manipulating bitmaps and reading and writing network data, all non audio, non webcam, and non disk usage related functionality would be possible, but it would be a waste of time".
posted by idiopath at 10:19 PM on January 14, 2010
I wrote (and then obfuscated) an unlambda interpreter once.
Obviously your point is morally correct, I just find the quick recourse to Turing machines kind of annoying in this kind of context—not all things that people do with computers are computations.
posted by kenko at 10:46 PM on January 14, 2010
Obviously your point is morally correct, I just find the quick recourse to Turing machines kind of annoying in this kind of context—not all things that people do with computers are computations.
posted by kenko at 10:46 PM on January 14, 2010
« Older It's always September 13, 1999 somewhere | Another Peek Inside Facebook Newer »
This thread has been archived and is closed to new comments
posted by GuyZero at 4:47 PM on January 13, 2010