Swiffy: convert SWF files to HTML5 | Hacker News Reader

Swiffy: convert SWF files to HTML5

googlecode.blogspot.com

254 pointsRobin_Message71 comments

> Which browsers support Swiffy output?

> Swiffy uses SVG features that are currently only supported by Webkit-based browsers such as Safari (on desktop and mobile) and Chrome.

That's not the HTML5 future I wanted :(

In Opera it fails due to JS errors that don't look SVG-specific. It's a shame, because Opera's SVG support is a bit more complete than WebKit's: http://www.codedread.com/svg-support.php (sadly the Swiffy's site doesn't say exactly which feature it needs)

Anyway, it's great that they're using SVG. Good use-case for SVG will help it get more love from browser vendors, and perhaps developers won't have to reinvent SVG with canvas :)

I don't think this is indicative of the future of HTML5 and I'm not so sure there will be a reason to use these SWF->HTML5 converters other than maybe a head start on re-developing your application. Have you tried converting a PDF to word? Converters for proprietary technologies haven't proven to be very effective.

The problem with both converting SWF and PDF into more 'open' formats is not that they're proprietary (SWF specs are freely available no anyone; not sure about PDF) but that they're final formats. PDFs, for example, retain information about how something should be rendered, not edited; hence why blocks of text get cut when trying to convert it to anything (there's no text flow information). In the same way, images are downscaled, transparencies are flattened or rasterized, fonts are broken down... there's too much lost. A SWF is the same; it'd be better to work from original files and projects (similar to what Wallaby is trying, and maybe Hype?) to 'compile' everything to HTML5 (or whatever output format) than trying to transcode something from a format that was optimized for one specific kind of player.

At this point I'm beginning to doubt we'll ever actually get to a fully cross-browser web. We've had two broad reboot attempts (first to "XHTML+CSS", the current one to "HTML5") and both times we ended up largely with a limited list of browsers and engines supported just as we had in the days of Netscape 4.x/IE4. The supported browsers are the cool browsers/engines of the day, which we then proceed to curse in three-four years. Only the names of the browsers change.

Edit: heh, didn't even notice who I was replying to.

The cross browser web already exists. It's called AS3. The only reason it gets a lot of bad press is that no one wants to snuggle up to Adobe. Meanwhile everybody flails around pretending that HTML5+JS will solve the problem, when that was already a dinosaur five years ago, and as you said will never be supported uniformly across browsers.

Edit: Here come the fanbois to downrate me. Consider your own karma. Downrating me does not change the facts on the ground. You cannot build a 3d racing game in HTML5+JS in the browser. Can you??? If you can, seriously, respond instead of hitting that little down arrow, and I would love to see what combination of technologies you employ!

Unfortunately, you are at least partially right. HTML5+JS might be an acceptable solution to lots of problems, but I don't see web game development moving away from stuff like Flash and Unity to a W3C standard. It probably has a lot to do with having to wait forever while the W3C labors to push any damn thing out.

I think you're getting downvoted for implying that something can be "cross-browser" that is locked into a single vendor. Your point is clear, but it exploits a nerdy little loophole in the definition of "cross-brwoser".

Not only that, but Flash isn't perfectly "cross-platform" either. It's really only a great experience on Windows and 32 bit and a crapshoot everywhere else, it's still the major cause of browser crashes everywhere else, has struggled with 64 bit implementations, has a long history of sandbox security problems, and their feigned "open source" efforts where there's proprietary parts they don't document or release garners them few OSS friends, downgrades poorly, is a significant resource requirement overhead, and isn't very accessible by default (the standard swf you encounter will not be blind-user accessible).

If Flash is the answer, we're in even worse shape than using HTML/JS.

It's totally not a nerdy loophole. If Javascript 2 / ECMA-4 was available in most browsers, it would be exactly the wide-open cross platform flash experience everyone wants. It's just that the only implementation of that, right now, happens to be done by Adobe. The specs are open, there's nothing secret about it. There are open source alternative players (gnash, flowplayer, etc), and Adobe made Flex 3 free for devs which is all you need to write any kind of app you'd like.

Look, the only reason there's ANY implementation of ECMA4 in the browser, i.e. Flash, is that a company which doesn't make a browser took it upon itself to create a plugin for all browsers that runs it. Now everyone hates them because it's "closed", which is ironic because IE's implementation of for example the matrix 'filter' -- just to pick one random thing -- is so ludicrously archaic and different from anything webkit, that there's zero, zip, nada, NO HOPE of those two things ever converging in a way that would let a single piece of code skew the same image in both browsers.

Anyway, to other people -- I work on mac, and I write code for both canvas and as3. I wrote this: http://strikedisplay.blogspot.com. Also wrote sexypolitics. Things are...what they are. You have to face reality and use the right tool for the job. And when JS2 comes out, sure I'll be there. 'Til then, long live Adobe. Beats the alternative Mozilla/Microsoft/Google mess.

> The cross browser web already exists. It's called AS3.

AS3 is not cross-AS3-player.

Does it have two (or more) interoperable implementations? Can it run on platforms not supported by Adobe?

While single-vendor closed-source plugin is strictly speaking cross-browser, it doesn't have things we want from "cross-browser" solutions:

• freedom to run it on any computing platform (people run HTML+JS on their Amigas, because they can!), now and in the future (what if Adobe decides that maintenance of Flash Player is unprofitable? How useful would be archive.org in 20 years when none of supported platforms is alive?)

• competition between implementations, so that if one stars sucking or does something user-hostile, competitors will take over (You don't have browsers with hidden hard-to-delete cross-site cookies — they compete on privacy features!)

> You cannot build a 3d racing game in HTML5+JS in the browser.

There's a quite convincing proof of concept that you can: http://helloracer.com/webgl/

It doesn't work on iPhone and I'm not sure if it works 64-bit Linux, but that's not a problem, right? :)

You're misappropriating the term 'cross-browser'. It does not mean open-source or open. It means the technology will run across most browsers. And Flash does that. You have some valid points but none of them seem to refute the idea that Flash isn't cross-platform.

I hereby alter my grand-grandparent post to read "platform independent" rather than "cross-browser".

Does Firefox's IETab make ActiveX cross-browser? It runs in more than one browser chrome! …except it relies on one-vendor's binaries and is limited to platforms supported by the vendor — just like Flash.

Even something that is "cross-browser" can have all negative aspects of a single-browser solution.

My point is that for HTML cross-browser is not the goal in itself, it's only a way to ensure that technology is freely implementable by anybody, that content doesn't rely on bugs in one implementation, that fully-functional implementations can be available 10 and 100 years from now if necessary.

"You cannot build a 3d racing game in HTML5+JS in the browser. Can you??? If you can, seriously, respond instead of hitting that little down arrow, and I would love to see what combination of technologies you employ!"

Just curious what disqualifies the easily googlable Mario Kart and Quake HTML ports?

I think it is just that it takes time for any new feature to mature enough that it is implemented in browsers interoperably. For example, the first implementations of a CSS3 module generally require vendor prefixes, but eventually it makes it to candidate recommendation, which is when they must drop the prefixes, because this is required (and also that tests pass that it is implemented interoperably) for the module to move to proposed recommendation.

It seems to mostly work out of the box in Firefox (tested in Aurora 6.0a1), although there were a few elements in some of the demos that did not render correctly.

first paragraph of TFA:

Last summer, an engineering intern named Pieter Senster joined the mobile advertising team to explore how we could display Flash animations on devices that don’t support Adobe Flash player. Pieter made such great progress that Google hired him full time and formed a team to work on the project. Swiffy was born!

what an awesomely productive intern! now that's a way to secure yourself a full-time job!

That probably should say: "joined the mobile advertising team to explore how we could display Flash advertisements on devices that don’t support Adobe Flash player"

Which is not really the cool HTML5 future anyone is looking for.

Anyone who is looking for the "cool HTML5 future" to be ad-free is going to be bitterly disappointed. Online ads predated the ubiquity of Flash, and they'll be around long after Flash is forgotten.

yeahhh... basically we can turn the last 15 years of annoying flash ads back into the modern equivalent of animated gifs. whoopee =)

At least animated GIFs are easy to disable and doing so tends to have less undesired effects than disabling Flash.

At least animated GIFs are easy to disable and doing so tends to have less undesired effects than disabling Javascript.

And since this is really replacing it with Javscript...

FTA == From The Article. ;)

You're right about the definition of FTA in this context. But TFA means The F(ucking|ine|*) Article in this context.

I bet it's not a typo.

I always thought it was "the featured article" if you were being polite.

Yes, that's possible. Sorry, I checked if I'm wrong here: http://www.acronymfinder.com/TFA.html , but didn't find anything relevant.

TFA is a Slashdotism.

It's counterintuitive but Adobe should be working on a project like this.

A decent server side SWF->HTML5 would enable existing websites to offer the first class experience (the SWF) to Flash enabled browsers, and push a HTML5 conversion for non-Flash browsers (Apple mobile devices). It would shaft Apple (Why does this run so slow on the iPad?) and slow the move away from Flash (Adobe could still make a credible 'runs everywhere' argument).

http://mashable.com/2011/03/08/adobe-wallaby/

Wallaby is a feature of the IDE to publish as HTML5 - it doesn't seek to address all the SWF content that is already out there.

Reality check: like it says, it converts a subset of Flash 8 content.

It means it converts a subset of content that was made for a version of Flash that is 6 years old (Flash 8 was released in 2005; Adobe is about to release Flash Player 11).

Sorry, this is not the "Flash killer" you're looking for.

Maybe I haven't been paying enough attention, but Flash circa 2011 doesn't seem all that much better than Flash circa 2005. If it gets them on iPhones, I think most people would happily take Flash 8 and possibly not even notice the downgrade.

Everything from Flash Player 9 onwards: http://en.wikipedia.org/wiki/Adobe_Flash_Player#Release_hist...

Too much stuff to mention, but the new VM especially. I personally haven't been working with AS2 (the old VM) in 3 years.

If one wants to create new content (and thus can "afford" to go back some versions) then this could be useful. Simple banners and whatnot maybe. But in that case, using many of the new HTML5 native editors is probably a better bet.

It'd be interesting if this progressed enough so that browsers could offer built-in conversion of Flash content to run it without the Flash plugin enabled.

Indeed. It's as if Flash is an addictive drug, and we are coming up with ways to ween ourselves off of it.

Flash was built to fill a gaping hole in the market. I think that hole is just about filled (or will be post HTML 5) for the majority of use cases. I see flash falling into smaller niche-based use cases in the near future.

Before this can happen, there needs to be a brain-dead easy to use IDE for creating Flash-like presentations in HTML5.

Right now, I see the biggest benefit of Flash being that I can purchase a number of IDE's and create some multimedia (or games) for the web in no time.

There are already tools like Sencha http://www.sencha.com/products/animator/

There's Edit Room, my product, a dead-simple CSS3 animation creation tool.

http://edit-room.com/

looks like it could use a little work in firefox 5 before it's at uh, flash level quality: (screenshot) http://www.opencombinator.com/editroom.png

Yes, firefox support will get there eventually... It just came out and I'm a solo developer - this is my side project. Thanks for checking it out!

I made this a few years ago, http://antimatter15.com/ajaxanimator/wave/

I started it when I was in sixth grade, some four years ago and it hasn't changed much in the past two years. Understandably, it's not nearly feature complete. It's actually pretty interesting that when I started out, the goal was to have Flash as the output, because embedding HTML just seemed so impractical.

The major downside is that most webshops are and have been using Actionscript 3 for the past 5 years. Has anyone compiled any AS3 with this?

Here is the output after trying to convert one of my projects:

9-slice scaling is not supported. (11 occurrences)

Pixel hinting on strokes is not supported. (10 occurrences)

Filters are not supported. (100 occurrences)

Shape tweens are not supported. (2 occurrences)

ActionScript 3.0 is not supported. (2 occurrences)

Advanced text rendering using continuous stroke modulation is not supported. (3 occurrences)

Some more errors here, just so we can start compiling a list of what is unsupported:

An unsupported SWF tag was encountered. (1 occurrences)

The global ActionScript property _quality is not supported. (1 occurrences)

Character glyphs aligned on pixel boundaries are not supported. (4 occurrences)

The #initclip pragma is not supported. (23 occurrences)

An unsupported audio codec was encountered. (1 occurrences)

A couple more:

Miter limit will behave differently, as it will revert to bevel instead of cutting off the joint. (65 occurrences)

Adjusting the font kerning within dynamic text is not supported. (7 occurrences)

Testing some (very) old SWF of mine:

Custom font kerning is not supported. (2 occurrences)

Streaming audio is not supported. (17 occurrences)

Blend modes are not supported. (6 occurrences)

Scenes are not supported. (1 occurrences)

Filters are not supported. (426 occurrences)

Adjusting the letter spacing within dynamic text is not supported. (1 occurrences)

Advanced text rendering using continuous stroke modulation is not supported. (5 occurrences)

ActionScript 3.0 is not supported. (2 occurrences)

stuff I did on flash 8... or just when drawing methods was released: SWF 6 (or later) clip actions are not supported. (2 occurrences)

The ActionScript method MovieClip.createEmptyMovieClip() is not supported. (1 occurrences)

My experience of HTML5 right now doesn't really have significant performance improvement compare to Flash, even on Mac OS X. I think it still has a long way to go. But it is nice to see someone's exploring the frontier! The blurring effect doesn't seem right though...

That really depends on what you want to do. The drawing performance for the canvas element has been dramatically improved in the last few months - for desktop browsers at least.

And then of course, there's WebGL; even if you just use it for 2D stuff (shameless plug: http://www.phoboslab.org/xtype/ ) it's way faster than Flash. I have no doubt that in a few month the the 2D canvas context will have the exact same performance (if not better) as WebGL for 2D stuff.

My experience of HTML5 is that it blows Flash out of the water. Flash on Linux is (still) an absolute disaster while HTML5 is making progress every day and has long surpassed Flash in usefulness for most tasks.

I'm very skeptical. Claims like this never seem to be born out in actual benchmarks.

http://pacoup.com/2011/02/03/flash-vs-html5-performance/

http://www.craftymind.com/guimark3/

The advantage of flash right now is that you can be reasonably sure that if a user has it installed, they will get a minimum set of features and performance. With HTML5, your complex app may run fine, or may not run at all, depending on the users implementation.

I've no doubt the performance gap between flash and html5 will continue to narrow. However, I'm less sure that there is anything in the design of html5 that would allow for implementations that are significantly faster than flash allows for. Perhaps someone with deeper technical knowledge of the two could comment.

HTML5 does have the advantage that it's an open platform, of course. Thus you are much more likely to actually see competing implementations of the standard.

Not so. I see people all the time who just get a "This content requires a newer version of Flash."

That can happen. Or users may not even have it installed. But contrast with the case of a user with a browser that doesn't support some features of HTML5. How do you detect which features work for them, and which don't? How can the user fix the problem?

The only way to fix it is to install a new browser, or perhaps a new version of the current browser. Installing a plugin is often easier. Rather than deal with this, developers currently just develop for and test on a few main browsers. Anyone not on these are left with no other options but to switch browsers.

Suffice to say, HTML5 doesn't really improve the situation all that much. It simply trades the closed model that Adobe uses with Flash for an open model that has been used for HTML. In either case, the only way to be really compatible is to use older well established features.

Open platforms are good, and thus HTML5 is a good development. But it's not the silver bullet that many make it out to be.

I agree. Especially Apple will try to compete heavily on HTML5 standards, since Flash is out of question for iPad, and iPhone. Since their devices only support Safari, HTML5 can certainly be optimized for it. Same thing for the rest of the world... kinda make it more complicated than Flash platform.

My experience is that your anecdotal experience is flawed and that Flash has a better workflow AND performance AND battery conservation on both desktops and mobile platforms (where it's allowed).

http://www.next-gen.biz/news/html5-still-lagging-behind-flas...

http://iq12.com/blog/as3-benchmark/

http://workflowed.blogspot.com/2011/02/flash-player-101-for-...

http://www.streamingmedia.com/Articles/Editorial/Featured-Ar...

http://pogue.blogs.nytimes.com/2010/10/07/testing-videos-on-...

http://www.androidtabletnows.com/android-devices-news/2011/n...

http://themaninblue.com/writing/perspective/2010/03/22/

http://vimeo.com/10553088

http://www.blackcj.com/blog/2010/09/17/flash-outperforms-htm...

http://www.craftymind.com/guimark3/

http://www.craftymind.com/guimark2/

But hey, let's complain about it because "Adobe is evil" or whatever! (and note: I'm an Ubuntu x64 user).

http://iq12.com/blog/as3-benchmark/

Is this what you wanted to post? This shows that the browsers' JS engines have been outrunning ActionScript for years now...

This is exactly what I wanted to post. My links cover all the spectrum of tests employed, not just tests that are favorable to Flash. GuiMark3, for example, found that HTML5 rendering of video in high resolutions on mobile devices tend to be faster than Flash video too, depending on version. I'm a defender of pragmatism, not of Flash, and it drives me mad to see people saying things that are just not true, like the previous poster.

My point is that if one analyzes the data, one will find that Flash tend to win over HTML5/canvas performance more often than not. The canvas and visual performance tests are very telling.

As a side note, there's definitely a gap in code execution - that's the link you posted - but it's just one of the factors, as Adobe is well aware of that and is addressing it on the next release. The AS3 VM was much faster than JS when introduced, then they spent a lot of time not doing any optimization at all. From what I've seen from their presentations, they're ready to take that back. Time will tell.

Every time I see a post about how HTML5+JS+CSS3 is so much better than Flash, they clearly are ignoring major subsets of what Flash does. First and foremost, browser-native audio processing is nearly a decade behind Flash. Not just in theory - toward the end of last year through February of this year, I set about emulating a fairly simple drum machine in HTML + Javascript, and while the fundamentals are basically there, the audio playback is atrocious on every single browser - try it out at http://bitrotten.com/dr110/

It was a fun experience, and maybe later this year I'll grab a trial of Flash and port it there, just to A/B them. But if you think HTML5 is going to replace Flash, you have a limited knowledge of what Flash can do.

I tried a handful of random SWF files from my dropbox and none of them worked. Several were due to AS 3.0, which isn't supported but even simplest animation said "The #initclip pragma is not supported.".

#initclip is an internal syntax used normally when using AS2 classes (it was auto-generated, although you could use it manually too), as it forced code to run before the normal execution cycle.

Seems to be limited to 512kB. Thats not much of a demo.

How does this compare to Gordon? https://github.com/tobeytailor/gordon/wiki

Both are ways to play flash content without flash but the approaches are quite different.

Gordon is a Flash runtime written in Javascript, allowing the browser to play SWFs.

Swiffy is a tool separate from the browser that converts SWFs into a form usable by browsers (SVG and JS).

Great example of misuse of the HTML5 buzzword.

Cool. Now if we only had a Silverlight -> HTML5+js converter we could quell the Windows 8 uproar.

I can't help but wonder if content owners might view this as a threat to the security of their flash creations. Afterall, this is essentially a decompiler, isn't it?

Plain Flash SWFs are trivial to decompile and decompilers have been available basically since the beginning of the platform. Anyone who really worries about that sort of thing is running their Flash output through obfuscators/minifiers similar to the ones available for JavaScript. With such obfuscated swfs you can still extract the code but it'll be basically an unmaintainable mess. I'm sure the output of such obfuscated code with this tool is just as bad as it would be if decompiling the bytecode to ActionScript, if not worse.

The SWF format is open (in the sense that it's a published spec) and many SWf decompilers already exist. This doesn't change anything in that regard.

Sweet! So all the obnoxious animation and banner ads can be converted into "HTML5" that runs 3x slower and sucks up 80% of a dual core processor per ad...and NONE of the actual coding, deep interactivity or UI enhancements implied in the ECMA4/AS3 platform are included. Is this the shape of things to come? Let me off this stupid ride, google. I vote DuckDuckGo, pageranks based on qualified user responses regardless of crawlable content, interactivity with client-side languages and structures that can't necessarily be crawled by a bot script, and an end to a monolithic, archaic system of ranking up corporate garbage.

BLOW ME, Google. Apple. HTML5 lovers. If anyone needs proof Flex/Flash won't be dead for a long time, here it is =)

You're obviously a windows user (and a flash "developer"), because for people on every other platform it's flash that chews up 80%CPU time and runs dog slow. Maybe if adobe hadnt give every other platform such shitty implementations, there mightn't be so many people working towards killing it.

Reply on news.ycombinator.com