Sunday, May 14, 2006
GPLFlash2 has faded into the mist. Folks who still want to follow development on a FLOSS SWF interpreter should check out gnash.
Sunday, July 31, 2005
More Dead Air, and More to Come
All right, folks; sorry again for the huge delay in posting. I've been letting my subconscious turn over the design (read: slacking off), and there are a few changes that will need to be made to some of the interfaces that I've defined so far. I'd really like to get at least the SWFIO design done before the end of the summer, but I don't think that's going to happen. Which leads to my next announcement…
I'm going in tomorrow (Monday) to negotiate a short-term, full-time job at a software company I have prior dealings with. Short of dire budget problems or a major catastrophe, I suspect I'll be employed starting August 11th to September 27th, and school will be starting up directly afterward. Furthermore, I'm going to be on a road trip and unavailable from August 4th to the 10th. Thus, I'm probably not going to have too much time to do anything really substantial for the rest of the summer.
Wednesday, July 27, 2005
SWFIO Filters Design
All right, I sat down and hammered out the basics of the SWFIO Filters package. I still haven't documented the semantics of all of the calls yet, but I know what they are (I just need to write them down). Once I get the semantics documented, I can write the unit tests — after that, I can implement the code, or leave that for someone else to do while I move on to designing other pieces.
I've updated the Umbrello diagram on the server (check the links at the left), and have also generated an image of the diagram (click the image below to see the full-scale picture). Enjoy :).
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.
Sunday, July 17, 2005
Sorry about all of the dead air lately. I have been rather distracted these last few days, so I don't have much to show :p. There are still a couple of news-worthy tidbits, despite my lack of concentration.
ffmpeg Dependency Issues
First off, thanks to willem for helping out with this matter.
So, it turns out that ffmpeg actually generates .pc files (for the pkg-config system), but how those files are handled varies from distribution to distribution. Under Debian, an ffmpeg-config script is installed, and other under distributions, the .pc files could be installed. Under Gentoo, none of those files is installed. Thus, I've re-written our ffmpeg test so that it looks for "ffmpeg-config" first, "pkg-config avcodec avformat" next, and then finally tries to just right-out look for "-lavcodec -lavformat" (or "-lavcodec_pic -lavformat_pic").
The main reason we have to use ffmpeg-config or pkg-config first is because on systems like Debian, the ffmpeg libraries are cross-linked to lots of other optional libraries. Thus, there is a variable list of -l flags that must be used in addition to "-lavcodec -lavformat", and it would be foolish to try to brute-force all of the possible combinations.
Edits & Corrections
kermit_ has kindly donated his time and skills as a technical writer. He's already made a few adjustments to the GPLFlash homepage, and he's presently working on annotating and cleaning up the contents of gplflash2/doc/. Thanks kermit_!
I've made various updates to the NPAPI docs (html, pdf, and texinfo source). The initial documents were totally, flat-out wrong in some respects. I could really use a Windows programmer and a Mac programmer to help me write the platform-specific parts of the guide. Anyone interested?
Tuesday, July 12, 2005
Scouting Documentation for NPAPI
I'm writing something that I've dubbed a "scouting document" — documentation that covers a whole topic that will affect us in the future, but only a subset of which I'm interested in at the moment. In this case, I've decided to take a detour and start working on a thorough and comprehensive NPAPI guide (since even the official documentation has some holes and misinformation). When someone in the future goes out to re-write our plugin (as I'm sure will happen eventually), this document will hopefully be the only thing they need to understand the requirements on the plugin side of things. I've been working on it for about two days now, and hope to have my research and first draft completed within a week. For those interested in alternate formats, the texinfo source document and pdf rendering are also available.
Monday, July 11, 2005
Someone, whilst looking over the diagrams in a previous post, asked me why the SWFContext package depended on the SWFIO package. The answer to that initial question is because the SWFContext package will (or has the high potential to) handle SWF tags, structures and/or primitives. I think it would be highly unlikely that, throughout the entire package, not one class or sub-package would handle objects from SWFIO. Handling (sans a higher-layer abstraction or wrapper) is enough to cause dependency.
The path that our discussion took, however, went towards "ActionScript only" coding, and how it wouldn't make sense to have just tags for keeping context in that case. This is entirely true: in a file where you have only two tags (an ActionScript and an End), the vast majority of the work is not going to be done with tags; it'll be done in the ActionScript VM, using context-saving methods that are designed for that purpose. However, note that there is no conflict here: SWFContext is a package, not a class. I used packages on purpose, because I really don't know enough about how the system should work overall (yet) to create classes.
Now, I surely haven't thought deeply about AS and how to design its implementation yet — and I most certainly didn't think about the situation of a completely programmatic SWF. However, the design does allow for these "future requirements" by creating appropriate extensibility points. To implement AS, we shouldn't need to change anything in the SWFContext package at all, nor should we have to change anything in the TagLogic package (aside from implementing the AS tag handler). Creating things inside of AS will be managed by the AS VM; the context will be allocated by that VM, and could then be stored in a variety of places (such as a void* in an STL map container, either in the TagData object itself, or back in some context object in SWFContext).
Now keep in mind that I made up most of the last paragraph you just read (that is, I hadn't planned it out in advance). The design is far from being coherent, let alone complete — it's just a rough roadmap for the time being. In fact, a very important detail (having a SWF- and/or tag-central location where multiple "plugins" can store independent contexts) came out of the exercise. I'm nowhere near touching AS, or rendering, or user input, or sound, or A/V sync, or any other of a million other broad and nuanced areas that the final player will encompass. That's why getting questioned and challenged along the way is ultimately a good thing — other folks can see the potential mistakes I'm making, and that gives me the chance to plan out and ensure I don't make that mistake. That is, after all, what design is about ;).
Asking the Mozilla Devs
All right; the long and short of it is that the "simple" plugin from last time didn't register or otherwise work. As such, I decided to pop over to irc.mozilla.org and see if I couldn't straighten things out directly with the developers. Apparently, the XPCOM plugin interfaces are deprecated >_<. So… there's no reason not to just use the plain-jane C NPAPI interface. I'll go ahead and design with that in mind.
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.