Monday, July 18, 2005


Cairo and GPLFlash

All right; I'm going to really drive the "Cairo will/won't work for us" argument into the dirt. I think it will work for us, and I'm prepared to do the research to back that hunch up.

This email is a bit deceptive on a couple of points, though not intentionally so. Cairo, first off, is a vector drawing library, which means it talks in terms of paths (curves/lines), strokes, fills, and transforms. Both SWF and SVG are vector-based formats; SWF uses only paths, strokes, fills, and transforms, whereas SVG uses these in addition to primitive shapes.

The big issue for correctly rendering SWF shapes is how fills are performed. The aforementioned email states that there are "left/right area[s]"; drawing on the spec, I'll elaborate a little. The specification says that there are two fill types that a path can have: "fillstyle0", which is applied to the left of the vectors in the path, and "fillstyle1", which is applied to the right of the vectors in the path. However, due to the examples and language used after this statement, I am under the impression that "fillstyle0" is for interior fills, and "fillstyle1" is for overlap/self-intersection fills, and that the left/right nomenclature was purely for the sake of example. The only way to find out will be to run a test through MM's player; I'll try to construct such a test in the near future.

Update: I have constructed tests. I have been totally unable to get MM's player to render "fillstyle1" and "fillstyle0" simultaneously. MM's player, for all intents and purposes, behaves exactly like "even/odd" filling, which Cairo provides. If anyone is interested in getting the test files and source code used to generate those tests files, ask me for a URL in IRC (any link posted here would probably go stale too fast).

Here's a table that compares SWF's functional needs with the drawing tools that Cairo provides:

RGB/A Solid fillProvided (sample)
Linear GradientProvided (sample)
Radial GradientProvided (sample)
Clipped Bitmap FillNot provided
Tiled Bitmap FillProvided (sample)
Stroke widthProvided (sample)
Stroke colorProvided (sample)
Moving Without DrawingProvided (sample)
Affine TransformsProvided (sample)
Drawing LinesProvided (sample)
Drawing Curves*Provided (sample)
Even/Odd FillingProvided (sample)

*Note that the Bezier curves must be converted from quadratic (SWF) to cubic (the rest of the world :p). This is a straightforward transformation.

The only thing I can see standing in the way of using Cairo is the "clipped bitmap fill," which takes a 1 pixel outline of the bitmap, then extends that outline as far as it needs to go to fill the area. I can't easily generate a test for this functionality to see how it works in MM's player, so I don't know if it will be easy to emulate (using something like imagemagick) or not.

You might want to take a peak at the swfdec-code since they use cairo.
I've taken a look at the source. It appears that they use the even/odd rule to fill, but it also looks like they handle only solid (RGB/A) backgrounds — no gradients, and no bitmaps (tiled, clipped, or otherwise).
hello, I just want to point to the fillStyle paragraph, don't know if it's late to say.

afaik fs0 and fs1 are valid in a contest depending on the drawing sense, and if shape have to be drawn in a single stylechange record (cfr. swf file format specification).

That's very important specially for "holed" figures.

jaco - pixeldump
Post a Comment

Links to this post:

Create a Link

<< Home

Note: I have been told by someone who recently downloaded the SWF specification that Macromedia has added a restrictive license to the end of the document. Because of this, newcomers will not be able to get a copy of the spec and still be able to contribute to GPLFlash's development. Since other developers (such as myself) already have access to the specification without the license, this should not pose a major problem in the short term. Please bear with us, and do not seek out or use this specification in conjunction with the GPLFlash project.