When Apple abandoned Flash on mobile devices, we more-or-less abandoned logo animation. Thanks to Swiffy, perhaps it’s time to revisit that decision. Let’s do some tests..
When we finally ported our website into a responsive layout back in July, I had to move some of our legacy blog posts over into this location. There was a lot of them – we’ve been blogging in one form or another since 2005 – some were still relevant, some not so much, some time sensitive, others still contemporary. I had to decide which to leave, which to delete (lots of dross had accumulated over the years) and which ones to revisit. One I moved over was a post from 2014 that opined Flash isn’t dead just yet, that talked about Swiffy, the (then) newish Flash to HTML5 conversion tool by Google. At the time, Swiffy was a little hit-and-miss – I had attempted to convert some older logo animations without success – and as we’d dialed back on animation as a result of Apple‘s lack of support, I’d forgotten about Swiffy entirely. After moving the post over (and updating it to explain the issue) I decided to give Swiffy another try. This is one result:
I selected this Vox Underground movie (logo case study here) because it’s a particularly complicated Flash (the logo was never suitable for 3D) and even then, it converted quite nicely. The “as is” size for this movie is 795px wide – much larger than it was ever intended for – and why it’s a little herky-jerky and low fidelity on the 3D polygons.
GIF animation vs. Flash vs. Swiffy.
Let’s break this down: the spinning logo at the top of this post (the little one) is an animated .GIF sequence pulled from the same source – an old 3D Flash animation (see here to see how it was built.) The .GIF is fine in a pinch but has some rather large restrictions. The image size has to be smallish, or the file size gets far too large (as it is, the featured animation is only 300 pixels wide and weighs in at 187kb) and we can’t scale it up due to standard pixel-based resolution issues. There’s not much we can do with the animation, save make it spin infinitely or for a limited number of rotations. GIF animations also have some anti-aliasing issues when output on a transparent background (edges can appear a little jagged.) The HTML5 animation (the big one) is vector based, so it’s scalable to large sizes. The transparent background is bang on with smooth edges. The key factor is that it’s responsive and will collapse for use on a smartphone or tablet, unlike a native Flash animation that won’t run at all on many devices. It’s pretty much the best of both worlds.
There are some downsides (of course there are): while Google tells us that the Swiffy HTML5 code is “a little bigger” than the original .SWF file, it’s more than a “little” bigger. The original .SWF for this animation was just under 500k (but it was streaming) while the Swiffy HTML5 code bloated to well over 1MB (though a lot of that can be mitigated with GZIP compression.)
A simpler test.
Granted, this is pushing Swiffy a bit, so let’s use a more conventional animation – this quick edit movie I worked on last summer (the logo was supplied by the client.)
The original .SWF file for that animation is only 15k. The Swiffy code is just under 200k which is a considerable bloat (though much smaller with GZIP,) so it appears (by our admittedly informal tests) the benefit of using Swiffy is more pronounced on the larger original file. One thing to keep in mind: these animations aren’t running as smoothly as they should be because there’s multiple scripts running on the same page at the same time. To use these on a website, we could add a Flash sniffer code that serves up the native Flash version on a desktop visitor, and the Swiffy code on a Flash-restricted mobile device or tablet.