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 fill||Provided (sample)|
|Linear Gradient||Provided (sample)|
|Radial Gradient||Provided (sample)|
|Clipped Bitmap Fill||Not provided|
|Tiled Bitmap Fill||Provided (sample)|
|Stroke width||Provided (sample)|
|Stroke color||Provided (sample)|
|Moving Without Drawing||Provided (sample)|
|Affine Transforms||Provided (sample)|
|Drawing Lines||Provided (sample)|
|Drawing Curves*||Provided (sample)|
|Even/Odd Filling||Provided (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.
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
Links to this post:
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.