I just de-minified the source code and this thing is a seriously impressive piece of work. It reads the SWF binary in JavaScript, decodes it (including extracting embedded JPEGs, sound files etc) and then renders the same content using dynamically generated SVG - if you fire up the Web Inspector in Chrome while it's running you can actually see the different SVG properties changing as it runs.
To pull that off, the JavaScript includes a base64 decoder, unzipping code, a ton of byte manipulation stuff for dealing with the SWF format and a full-blown ActionScript bytecode interpreter!
I've posted the de-minified version as a Gist if anyone wants a look: http://gist.github.com/418177 - for educational purposes only since the code hasn't officially been released yet.
Why give out the source? Why not turn this into a service? I know that there are a few ad agencies out there that would pay to see some of their investments run on the iPhone OS. Or content providers guarantee their sponsors' flash ads get impressions on iPhone/iPad.
This looks a lot like Gordon (http://github.com/tobeytailor/gordon) — a JS implementation of Flash. In which case, the point is that you don’t need a service to convert your files — your SWF files would work as-is.
Ideally — provided JS performance catches up — you simply re-tool your templates to use the JS runtime (rather than embed tags) to run your SWF file.
In fact, looking at the source of http://smokescreen.us/demos/lyrisdemo.html it’s conceivable that you could use Flash if available, but fallback to Smokescreen/Gordon otherwise (likely testing for HTML5 support first). That link is also a great example of how easy it would be for an ad agency to continue to use their existing resources for Flashless, HTML5-ready devices.
Is there any relation between the Smokescreen and Gordon projects? I haven’t heard of the latter in a while.
It's Javascript, right? You are going to give out the source whether you like it or not.
Now, in theory you could keep the source under exclusive license and sue people who put it up on their own sites without paying. In practice that business model will suck. A sizable percentage of potential customers will hate you. You will probably hate yourself. You will have to spend money on obnoxious lawyers. Basically, you will be a patent troll without the patent. (Or maybe you get a patent and then join the ranks of the patent trolls. Of which there may be quite a few. Perhaps another reason to just throw this code out there is as a pragmatic defense against patent trolls; it's like dropping your wallet and running away when confronted with a mugger. I believe that, technically, an amorphous, international group of pseudonymous open-source contributors has the same patent liability as a single private company, but they are a lot harder to sue effectively.)
But the biggest problem is cost of sales and support. If you want to sell this code you have to convince the customer it will work. On every browser that matters. And not just on some demo Flash app: On the customer's app, because what do they care about anything else? And if it works today, there is no guarantee that it will work tomorrow, because the customer can change the original app at any time. By the time you finish designing the system to let prospective customers do an extensive trial run, and then negotiate the switch to a paid license, and then deal with the support complaints, and then deal with the refunds when the customer decides that your software is missing Obscure But Apparently Essential Dealbreaker Feature X, you may well have eaten up more money than you can effectively charge for a product that, after all, is not exactly AutoCAD. [1] Perhaps it is better to throw the software out there and let it find its own customers.
---
[1] I'm not saying the software is less impressive or complex than AutoCAD. What I'm saying is that it doesn't have the market. People pay thousands for AutoCAD because it provides thousands of dollars worth of value to their engineering businesses. But there's a limit to what you can charge for a Flash-to-HTML5 converter: at some point it is smarter just to have your app converted to native HTML5.
Well, don't forget this is while reading and converting a swf in javascript commands. It's a lot faster when you don't have the abstraction layer. So for most things, yeah, javascript+canvas is more than enough.
Yes! In fact, if you view source, you can see that there's just a call "new Smokescreen(url, element, width, height, name, params)" which loads the SWF and renders it. (Much like Gordon, mentioned in another comment.)
There are always easter eggs in these strong bad emails. At the end, after the line printer sheet comes down, click on the lower light switch and the easter egg appears. To make it go away, you're supposed to click on the easter egg but on mine, it just makes everything disappear and the music loops indefinitely.
I also notice Strongbad's "mouth hole" sort of didn't look right, either, like there was this nested circle of some kind.
Well, Gordon only supports Flash 1 and 2; most actual Flash on the Internet probably uses some features introduced in the following eight versions. I can't find any specs on which Flash versions Smokescreen supports, but I would bet that StrongBad Emails aren't old enough to work in Flash 1 or 2.
To pull that off, the JavaScript includes a base64 decoder, unzipping code, a ton of byte manipulation stuff for dealing with the SWF format and a full-blown ActionScript bytecode interpreter!
I've posted the de-minified version as a Gist if anyone wants a look: http://gist.github.com/418177 - for educational purposes only since the code hasn't officially been released yet.