다음을 통해 공유

Converting Flash Shapes to WPF

  • 아티클

You may recall my post last month titled File Formats for Conversion to XAML. In that post, I asked which formats make the most sense for conversion to XAML for use in WPF applications. In addition to the blog feedback, I've received a lot of e-mail, and I've heard from fellow Microsoft employees who are working with our early adopters. Among the 2D requests, Adobe/Macromedia's Flash format comes up quite frequently. So, I decided to use some spare time to investigate what kind of effort it would take to convert SWF files to WPF/XAML.

A few searches quickly turned up A Concise Guide to the SWF File Format and Alexis' SWF Reference; both are very useful references. The SWF file format employs some unique bit field types that make parsing the file—how shall I say—interesting. Fortunately, I used to work with stuff like this all the time, so it didn't take too long before I had written a handy BitReader class to make life a lot easier. Perhaps I'll use it as the subject of a future post.

The SWF file format contains a number of tags that either define data or control the data that has already been defined. It's the combination and order of these tags that allow the SWF file to represent shapes and other assets that move over time. Although it's not the subject of this post, animation in the SWF file is frame-based. That is, shapes are first defined and then placed on the display using transformations. Then, the machine waits the period of a single frame, and the next set of tags is processed to transform existing assets such that, over the course of time, movement is achieved. To convert SWF frame-based animation to WPF timeline-based animation looks like it will require some inference. More on that later.

For the DefineShape tags, geometry is represented in a way that makes conversion to individual WPF elements a bit tricky. Although the diagram below may appear to be an orange rectangle on a layer above a blue rectangle, in fact, this is a single defined shape in the SWF file, and what appears to be an obscured area of blue doesn't actually exist at all. I'll use this compound shape to illustrate how the SWF file stores its geometry. I'd recommend that you consult one of the aforementioned resources if you want to know all of the detail. For my purposes, I'm going to gloss over some of the detail so that I can focus how this is relevant to WPF.

As you may know, geometry in WPF can be stroked (outlined) and filled using a variety of different brush types. However, any geometric shape can only have a single stroke type and a single fill type. If we were to represent the rectangles below in WPF, because of the two different solid-colored fill types (blue and orange), it would require two shapes. We'll come back to this.

When a shape is defined in the SWF file, the first thing that's defined is its line (stroke) styles and fill styles. For the shape below, there are no line styles, and the two fill styles are solid blue and solid orange. Following the styles, a setup record selects which line style and fill styles will be used to draw. Because the SWF format specifies that any line segment can have a fill color to its left and to its right, you can imagine the setup record as saying something like: "grab this pen, and dip my left-side brush in this paint and my right-side brush in this other paint." What follows is then a series of straight or curved line segments referred to as edges.

For the shape above, I've listed its edges in a table to the right. Each edge segment is listed with corresponding left and right fill styles. Although they don't appear in this list, there are setup records before the first AB segment (to "dip" the right brush in solid blue), before the EF segment (to dip the right brush in solid orange), and before the AI segment (to dip the left brush in solid blue). If you follow each segment in the diagram, you can see how the right and left fill styles correspond to the final shape. Note that the segments in my example are conveniently connected to each other in the order that they're listed. Although I haven't run across it yet in any of my sample files, the file specification documents above indicate that segments can appear in almost any order, so prepare for this.

Here's the general algorithm that I use. When I encounter an edge segment, I add it to an array of segments that includes its start and end points along with the current line style and the fill style to its right (choosing to store the right fill style was completely arbitrary on my part...similar logic would work if you chose to use the left fill style). For segments that only have a left fill style (none in my example), I swap the start and end points, which effectively flips the segment and allows me to convert a left fill style into a right fill style. For segments that have both left and right fill styles, I add two segments to the array: one with the normal right fill style, and a flipped segment with the left fill style converted to a right fill style. For example, when I read the AI segment for the shape above, I store two segments:

  • Start point = A, end point = I, line style = null, right fill style = solid orange
  • Start point = I, end point = A, line style = null, right fill style = solid blue

After the segments have been collected, I take all segments with the same line style and right fill style and consider them part of the same figure (note that this can result in disjoint geometry). Then, for each figure, I run an algorithm that connects segment end points to start points and references them using a linked list. I'm sure I can find a faster algorithm to accomplish this last step, but for testing, the naïve method works just fine. As I mentioned, you may end up with some disjoint geometry in your figures. For example, imagine a single shape that contains two non-intersecting rectangles with the same line style and fill style. So, when you spit out your WPF geometry, don't assume that each figure only has a single starting segment (i.e. a segment with no prior segment).

I'm sure there are cases that I haven't encountered yet, and frankly, my current investigations are only so that I can appreciate the scope of the problem. Fortunately, once you have code that reads DefineShape tags properly, it appears that you've also done most of the hard work for parsing character shapes too.

Beyond shapes, media, transformations, linear and radial gradients, and clipping, animation looks to be the next challenge. Because of the frame-based nature of data in a SWF file, I imagine that it'll be a bit more difficult to infer the original timeline-based intent of the animator. However, I'm confident that this can be done, because products like Eltima's SWF to FLA Converter have to perform similar logic.

For the truly ambitious, converting ActionScript to something like C# would be the final step. I haven't gone this far in my investigation, but I'm sure that someone out there can do it.

Is it you?

Comments

  • Anonymous
    March 15, 2006
    The comment has been removed

  • Anonymous
    August 28, 2006
    First, a sincere thank you to everyone who sent me daily e-mail reminders of the three Dell XPS M1710...

  • Anonymous
    October 15, 2006
    Wow! it's been about 2 1/2 weeks since I last posted, and it seems like forever. In the meantime, I've

  • Anonymous
    October 16, 2006
    原文: http://blogs.msdn.com/mswanson/archive/2006/10/15/example-c-code-for-reading-flash-swf-files.aspx

  • Anonymous
    November 21, 2006
    Finally! After months of tinkering around in my spare time, I've managed to assemble a relatively useful