Have a Flash SWF File? convert it to HTML5 with Google Swiffy(google.com)
google.com
Have a Flash SWF File? convert it to HTML5 with Google Swiffy
http://www.google.com/doubleclick/studio/swiffy/
9 comments
If you're thinking about using this, you might also consider Gordon (https://github.com/tobeytailor/gordon) or Smokescreen (https://github.com/cesmoak/smokescreen). Gordon's simpler -- very easy to follow code. Whereas Smokescreen, like Swiffy, offers support for audio and AS2. I integrated Gordon into my HTML5 game yesterday to render a walk cycle SWF and the framerate didn't drop. I'm going to do the same thing with Smokescreen next.
Swiffy saved the day for us recently on a project where we needed an animation to support IE7+ as well as iPad. We were able to have our designer create a flash animation and upload to swiffy to test that the conversion worked. We then used the swf as a fallback for when canvas was not available.
The one HUGE drawback for me with swiffy is there was no standalone compiler that we could use and integrate into the site build. So we now have this manual step of converting the files on the (hopefully still functioning) swiffy website every time a change is required to the animation.
The one HUGE drawback for me with swiffy is there was no standalone compiler that we could use and integrate into the site build. So we now have this manual step of converting the files on the (hopefully still functioning) swiffy website every time a change is required to the animation.
I guess it shouldn't be too hard to write a tool which automates that. You could probably even just use curl. I also trust that Google has enough interest in HTML5 adoption that they will make sure that this tool will continue to function.
Moderately complex intro animation from an old e-learning course I did converted successfully (failed on earlier versions of this tool so obviously they've been improving things).
No sound, not much scripting but lots of timeline animation with masked images.
swf: 205kb html: 352kb
(not including the swiffy runtime.js)
Not bad considering all the images have to be base64 encoded.
Generated code looked... generated... But not too awful. You could probably do something with it if you needed to.
However - it's no worse than trying to modify a swf file. You just wouldn't unless you ran it through a decompiler first and I don't see why that wouldn't be possible here also.
In most cases you'd go back to the FLA file or the XML equivalent and modify that instead.
No sound, not much scripting but lots of timeline animation with masked images.
swf: 205kb html: 352kb
(not including the swiffy runtime.js)
Not bad considering all the images have to be base64 encoded.
Generated code looked... generated... But not too awful. You could probably do something with it if you needed to.
However - it's no worse than trying to modify a swf file. You just wouldn't unless you ran it through a decompiler first and I don't see why that wouldn't be possible here also.
In most cases you'd go back to the FLA file or the XML equivalent and modify that instead.
I'm glad you liked it and it zipped down to such a small size (I worked on Swiffy file size reduction as an intern. Without the runtime, we were often smaller after gzipping :D)
Are those sizes before or after gzip compression ?
Before. A quick test by just zipping them up gave:
html: 209kb swf: 205kb
Does anyone know whether 'on the wire' gzip would give similar benefits?
html: 209kb swf: 205kb
Does anyone know whether 'on the wire' gzip would give similar benefits?
Two notes:
1. Zip uses a different algorithm than gzip - the results are not necessarily equivalent.
2. If the HTML is static, which seems to be the case (since it's generated manually from the SWF), you can pre-gzip them instead of forcing the server to do it on demand - that'll reduce latency and CPU usage. Therefore "on the wire" is not really relevant.
1. Zip uses a different algorithm than gzip - the results are not necessarily equivalent.
2. If the HTML is static, which seems to be the case (since it's generated manually from the SWF), you can pre-gzip them instead of forcing the server to do it on demand - that'll reduce latency and CPU usage. Therefore "on the wire" is not really relevant.
Zip and gzip both use DEFLATE.
Tried to recode random Масяня cartoon, it wouldn't play and would not support audio even if it would.
Literally yesterday I had conversation about the coming wave of flash to HTML5 conversion tools and services. Expect to see alot of effort going into conversion automation. Yes there will always be a need for hand crafted conversion but a lot can and will be automated.
> flash to HTML5 conversion tools and services
Which is a horrible thing. Images there are like 20 canvas elements on a page drawing animated ads. I am sure Macbook fans would roar higher than Flash
Which is a horrible thing. Images there are like 20 canvas elements on a page drawing animated ads. I am sure Macbook fans would roar higher than Flash
Machine generated HTML5.. hmm something in the back of my head tells me if you file isn't massive, its worth doing it yourself because it might produce bloated code. i.e it will be kind of difficult to work on that code later yourself.
Swiffy can't handle files input SWF files larger than 1024 MB and will display an error to that effect if you try. It might be more user-friendly if that fact were displayed on the file upload page. Just a suggestion!
Too bad this doesn't work in all browsers yet.
Now if they could just port playerglobal 11 to Javascript, we can run Molehill games in Canvas. Think how happy everyone will be to get that CPU-intensive Flash plugin out of their browser, when they find that now every website chews up 400% more processing power. A cynic might think they were promoting Javascript over AS3 so everyone would have to buy a round of newer, faster phones once these SVG animations start hitting the web.
You already have tools that do that, like http://jangaroo.net
Just for large project switching to an interpreted language like javascript with another layer of abstraction to emulate the flash API is too much of a performance hit.
Just for large project switching to an interpreted language like javascript with another layer of abstraction to emulate the flash API is too much of a performance hit.