No big news here… just tying together observations on different types of file formats, and how they interact with different types of local runtime engines.
some all SWF1 tags [demos]. It’s in the spirit of the previous “SVG in SWF” work from Helen Triolo, Claus Wahlers, Brad Neuberg and others — rendering one file format in a runtime designed for a different file format. Geeky, and admirable.
I liked seeing Gordon arrive, because it proves that SWF, SVG and such are just file formats, interconvertible with varying degrees of fidelity — of the same species. Neither is a black box, both have been publicly specified for over a decade, and different types of code can produce, consume, and work with them. Anybody can use either, do whatever they want with ’em. SWF and SVG are both useful and flexible file formats.
Using instructions in unexpected ways is fun. Different examples include Microsoft Gestalt (writing Ruby or Python in an HTML page), Flash Pro (the announced ability to export ActionScript as iPhone-native), much of the Flash 3D work (taking the Collada modeling file as a datasource). On the flip side, XML is a file format which was expressly designed for universal use.
But each of these file formats is then processed by an engine of some type, often a clientside runtime. It’s the interaction of format and runtime that determines the actual feature set, the actual performance, the actual deployment cost.
Here’s an example of the confusion: “While the open source Gordon is available to all, it still doesn’t solve one of Flash’s biggest problems. These SWF files still hog the CPU. One demo, a simple vector graphic of a tiger, throws my desktop browser up to around 100% CPU usage.”
Do you see the problem? The author assumes that his performance is controlled by the content — the instructions — rather than the way those instructions are processed in his environment.
Perhaps the most concerning type of theme: “Any developer wishing to get their Flash files to work on iPhone just needs to ensure they include a HTML wrapper and through the power of Gordon it should ‘just work’.” Here there seems to be an assumption that all runtimes are interchangeable, and that certain file formats are more magic than others.
It’s fun to use file formats in unexpected ways. But different runtime engines are tuned for different jobs, optimized for different types of instructions. Flash’s textfields can display HTML, but you wouldn’t use that to replace your local dedicated HTML-eating runtime engine. Different runtimes are engineered to take best advantage of different file formats.
I like the Gordon project, because it shows there’s nothing mysterious about SWF. Just like HTML, the file format definitions have been public for over a decade. They’re of similar nature, similar usability.
There are differences — SWF is binary, rather than text — that’s a meaningful difference. Another difference is that HTML is about hypertext, while SWF has been designed from the start for rich-media interactivity. Or you could argue that Adobe has provided saner governance over SWF than the WhatWG Consortium has over “HTML5”. The biggest difference between SWF and HTML is likely in the predictability of the runtime engine.
[Update: Changed “some SWF1 tags” to “all SWF1 tags”… my apologies to Tobias, I had forgotten that the FutureSplash Animator version had only a dozen logic elements!]