Gordon, formats, runtimes

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.

Last week Tobias Schneider released a project named Gordon, a JavaScript library which parses a SWF and renders 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.

But some of the reaction was a little strange — I’d rather not embarrass people by linking to articles, but (edited) titles like “Gordon Lets You Run Flash On Your iPhone” and “Open Source JavaScript to Replace Flash?” give a flavor. Much of the initial commentary did not seem to distinguish between a file format as a set of instructions, and a runtime as the clientside engine which executes those instructions.

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.

Another example: “This frees Flash from requiring a plug in. But it’s also a proof of concept that shows that you can do all the cool, propritary-plug-in stuff using just plain HTML.” Even if this JavaScript library could acceptably handle all the SWF10 tags (instead of some all SWF1 tags), it would still be a JavaScript library, downloaded afresh each time. Sending your runtime code as file format is not as efficient as using a native local runtime engine.

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.

When a Gordon project “runs on an iPhone”, it’s actually a SWF being parsed by JavaScript instructions which are executed by Apple’s Safari runtime engine. Although this SWF file format is being used, it’s more properly a Safari app than a Flash app by that point.

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.

There are differences between HTML and SWF, but even a JavaScript engine can understand simple SWF files… nothing mysterious or alien about it.

[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!]

4 Responses to Gordon, formats, runtimes

  1. Joe Wood says:

    Very true. Which is why HTML 5 cannot replace the need for a better client platform, what would be needed proper browser VM with a bootstrapped rendering engine.
    One point though – isn’t Gestalt actually just an invisible Silverlight object running the DLR and using HTML DOM interop? Unless you can call language just-in-time compiling an unexpected way to use an instruction.

  2. To me the differences have always been twofold (please correct me where I have misunderstanding):
    * SWF is effectively controlled by one vendor, in some cases requiring licensing fees paid to said vendor in order to bundle the player on a device
    * SWF does not “live in the DOM”, have access to the surrounding page elements, etc. From that perspective, a SWF is mostly a black box (that’s where I’ve usually heard and used that term w.r.t the Open Web) with a few knobs (parameters).

  3. Rui Silva says:

    John,
    This is definitely one of the best articles I’ve ever read about the subject! Thanks for sharing your thoughts!
    @jeff
    SWF content in a web page is not a black box per se. Flash provides an external scripting bridge that may be used both to access Javascript and the html where it “lives” an to allow Javascript code to access its contents. It would be better to regarding swf in a webpage as a protected box where the developer has a choice on what and how its content is accessible from the outside.

  4. paw says:

    The question if a solution requires a 100% predictable result to the end-user makes the difference.
    A fileformat is a fileformat is a fileformat. A file format isn’t the solution. A standardized predictable result to the end-user might make a file format part of a solution. Not the other way around.
    Eg. standardizing a vector and/or ria file format without delivering or having a binding reference implementation for its digestion produces nothing more than solutions in search for a problem. Prominent file format example: svg. On the other hand an example for an implementation set at odds as a fake solution in search for a problem: gordon.
    Anyways, concerning vector graphics, unpredictable results are only acceptable for those who can ignore the voice of the customer.