The Secret Life of SWFs: Flex 2’s undocumented SwfxPrinter tool

April 8, 2007 on 12:35 am | In Flex, Programming, Uncategorized |

It’s apparently a well-kept secret, but the Flex SDK includes a very useful tool for examining the structure and contents of SWF files. The Java class flash.swf.tools.SwfxPrinter, which lives in the Flex 2 SDK’s lib/swfkit.jar library, is an undocumented utility that dumps AS3 SWF files as XML documents. These dumps can provide really useful insight into what is taking up space in a compiled AS3 Flash or Flex application.

If you’re in the FLEX_HOME/lib directory you can run it as follows:


java -classpath asc.jar;swfkit.jar flash.swf.tools.SwfxPrinter [options] swfFilename

Here’s a somewhat random excerpt from some output; this includes some Flash sprite definitions:

  <DefineSprite id='28'>
    <!-- sprite framecount=1 -->
    <PlaceObject2 idref='27' depth='2' matrix='t0,0'/>
    <ShowFrame/>
  </DefineSprite>
  <ScalingGrid idref='28' grid='(80,80),(1200,360)'/>

The valuable -showoffset option causes the output to include the offset and size of each element in the file. For instance, the following DefineFont3 element shows the size of an embedded font from a Flex CSS stylesheet:

  <!-- offset=86441 size=35356 -->
  <DefineFont3 id='112' font='Myriad' numGlyphs='232' italic='false' bold='false' ansi='false' wideOffsets='false' wideCodes='true' shiftJIS='false' langCode='0' hasLayout='true' ascent='17019' descent='5120' leading='614' kerningCount='0' codepointCount='232' advanceCount='232' boundsCount='232'>

Sadly, in a regular application SWF, there is no information about how the code is broken up; all you get is a single element representing the entire code of the application in a single lump:

  <!-- offset=291066 size=1338571 -->
  <DoABC2 name='frame2'>
  </DoABC2>

Not to worry. Far more useful are the results of using SwfxPrinter on the SWF that’s inside a SWC (just use any ZIP decompression tool to unpack library.swf from a SWC file). Now you’ll see information like this:

  <!-- offset=2130104 size=4192 -->
  <DoABC2 name='mx/effects/CompositeEffect'>
  </DoABC2>
  <!-- offset=2134296 size=670 -->
  <DoABC2 name='mx/effects/Parallel'>
  </DoABC2>
  <!-- offset=2134966 size=4111 -->
  <DoABC2 name='com/allurent/containers/AnimatedViewStack'>
  </DoABC2>

Now that’s more like it!

So… I’m in the process of writing an Apollo-based tool that analyzes SwfxPrinter dumps, along with the linkage dependency information found in a SWCs, and allows developers to analyze both code size, linkage dependencies and associated source code/documentation in a single environment. Granted, it would probably make more ultimate sense to do this as an Eclipse plugin alongside Flex Builder, but which would you rather do to read in swfx dumps: deal with the Java XML APIs or hack some E4X? Also a lot of the analyzed information is easy to display in HTML, and Apollo has that nice built-in web browser.

Here’s a screen shot of some work in progress:

screenshot

One can use a tool like this to find out exactly how much space each individual class or package in the application takes up, and use that to tune its space requirements, Module loading strategy, and so on — this takes a lot of work, of course, but it’s a lot easier with the right information at one’s fingertips.

I’m thinking about the dependency-analysis angle. My current thought is to support two complementary approaches: 1) discover what other classes a given class/package depends on (and thus drags into the SWF), and 2) discover which dependencies caused the inclusion of a given class/package in the SWF. The first approach is useful when one has a good heuristic notion about what should be separated out (like a complex but rarely displayed view). The second is useful when you can see a large bunch of code and you’d like to understand what other stuff is using it, so you can separate out that stuff and avoid dragging the expensive code into the SWF up front. Either way, you identify candidate classes for modification, removal, or placement in a loadable module, in the name of a smaller download size.

Note: A somewhat more convenient way to run SwfxPrinter is to just copy this swfxprinter.jar file into FLEX_HOME/lib; then you can run it in any directory as follows:


java -jar %FLEX_HOME%/lib/swfxprinter.jar [options] swfFilename

(I’m not redistributing any Adobe code here of course; the JAR file just contains a manifest with references to class and library names.)

12 Comments »

RSS feed for comments on this post. TrackBack URI

  1. All I can say is, wow! This can be useful, I wonder how much overlap the Flex profiler (that might make Moxie) will have with some of the ideas you present here.

    Comment by Renaun Erickson — April 8, 2007 #

  2. I’m really looking forward to the size tool!

    SwfxPrinter has a lot more interesting settings which I’m guessing you’ve already found. :)

    One thing to note is that SWCs are built slightly differently than SWFs and will produce different sizes. You should be able to get things the same with the compiler options- I think you just need to set optimize=true and debug=false.

    Comment by Brian Deitte — April 8, 2007 #

  3. On the topic of link report visualizing, take a look at my post on the subject:

    http://blog.iconara.net/2007/02/25/visualizing-mxmlcs-link-report/

    I find it odd that the sizes are in comments in the SWFX files, it makes them harder to retrieve using XSL or DOM-programming.

    Comment by Theo — April 8, 2007 #

  4. […] Undocumented Component : SwfxPrinter […]

    Pingback by Robert Shiue&#8217;s Blog &#187; Blog Archive &#187; Excellent Flex Extensions — April 9, 2007 #

  5. Just awesome. Any chance you’ll be releasing the Apollo app? How’d you figure all this stuff out?

    Comment by Tom Lee — April 9, 2007 #

  6. Interesting. As for your SizeAnalyser, you should be careful to take into account SWF compression. It’s actually quite difficult to know the exact size a class is taking in a SWF, since you could take into account its dependencies, and the actual size difference of the compressed SWF with and without this class.

    Comment by Nicolas — April 9, 2007 #

  7. A few quick responses to questions that arrived this morning–

    Brian, thanks for the observation re optimization and code size, I knew there was some obvious reason for the SWC/SWF discrepancy but I didn’t think of the optimizer. (I knew it wasn’t debug b/c I turned that off first!)

    Theo, it sounds like I should be looking at link reports as well (or instead) for size analysis purposes. It certainly is odd that the sizes are in comments in SWFX dumps, but comments are optionally preserved by most DOM APIs including E4X.

    As far as compression goes, I have established through experiment that compiled AS3 code on average takes about 43% of the space of uncompressed code; this gives a rule-of-thumb adjustment for size yields. For fonts, it’s about 72%. These numbers come from extracting subranges of the file as indicated from the SWFX dump and doing gzip compression on them. One could use that technique for individual classes too; I should probably try a few random classes to see if they differ much from the average.

    Comment by joe — April 9, 2007 #

  8. A brief followup on link reports: for pure size and dependency analysis, these are better than the SWFX output since they combine the salient SWFX details with the dependencies in a pure XML format without comments. Also, they can easily be created as a byproduct of an existing compilation process. So I’m probably going to base ongoing SizeAnalyzer work on the link report instead.

    The SWFX dump is still a unique resource for establishing what else is going on in the file with respect to fonts, font glyphs, graphics/shapes, embeds, SystemManager overhead, and so on. And it does work on regular Flash SWFs, for which link reports are not available AFAIK.

    Comment by joe — April 9, 2007 #

  9. Hi Joe,

    This is fantastic. Since you aren’t continuing with SWFX dev, may I ask that you release what you do have for that so I can take it up and build a font-lister for swf files? With complex projects comprising multiple swc’s (some Flash, some Flex), fonts can become hairy very very quickly.

    A tool which quickly shows what fonts are defined for a given SWF/SWC is golden at times like this!

    Thanks for sharing such wonderful advice!

    Comment by Robert — May 24, 2007 #

  10. At this point, I’ve switched my tool development to work off of the mxmlc Link Report XML file, since it’s a bit more accessible and easier to work with. That also has font information in it.

    I need to find time to get the app into a state where it’s usable. One problem is that it’s running on an unreleased beta of Apollo right now. Eventually it’ll get into a state where other folks can run with it though.

    Comment by joe — May 24, 2007 #

  11. […] http://joeberkovitz.com/blog/2007/04/08/secret-life-of-swfs/ […]

    Pingback by TroyWorks &#187; Blog Archive &#187; Sketch: View Controller separation, MovieClip.addFrameScript — August 29, 2007 #

  12. […] while ago, I ran across a post by Joe Berkovitz that talks about Flex’s undocumented SwfxPrinter tool. After looking at the […]

    Pingback by Soph-Ware Associates | Blog — December 10, 2007 #

Leave a comment

XHTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <code> <em> <i> <strike> <strong>

Entries and comments feeds. Valid XHTML and CSS.
All content copyright (c) 2006-2007 Joseph Berkovitz. All Rights Reserved.