JSwiff Forum

Ralf

I've been asked to compare the JSwiff framework with the API offered by Flagstone, the Java edition of Transform SWF. Transform 2.0.3 was released in October 2004 under a BSD license.
First of all I have to say that it was last year when I first got in touch with Transform, but my experience with it was rather superficial, as by that time I had developed my own Flash API. At first glance, Transform didn't seem too transparent to me. In order to compare it to JSwiff, I'll have to take a closer look.
Although I'm the developer of JSwiff and therefore a 'competitor' of Flagstone, I'll try to provide an objective view of their API - and I'm pretty sure that won't be possible

Ralf

The Website
After a closer look at the Flagstone website and especially at the Transform SWF pages, I have the impression that Transform, once a commercial product, has been released to the open source community and since then it has been pretty much abandoned, especially the Java version, which I review here.
The following statement is pretty confusing:
"Optimization of the code used to log events with FSMovieListeners. Most of events are generated when the Transform.DEBUG flag and are used to support earlier versions of Describe SWF. Now that code required to decode Flash files is now integrated into Describe the extra code will be removed from Transform SWF to boost performance and reduce the size of the compiled classes."
Does that mean that Flagstone first gives away the import part and then takes it back? Turns out that this is not the case (see below) - I don't know what code Flagstone talks about here, but I know that SWF file import is supported.
It doesn't seem that anything has changed since the initial open source release. Does this mean that the project has been abandoned?
We'll see - so let's download the code.

Ralf

First Impressions
Ok, I downloaded three archives: Transform, Translate (which seems to be an ActionScript 1 compiler) and some examples.
I unpacked the source code folders into an Eclipse project. Now let's take a look at the code.
Eclipse reports an error and some warnings. First let's see what the cause of the error is.
The error is not in the API itself, but in the examples:
class com.flagstone.transform.util.examples.BasicShapes, line 164:
path.elipse(-width/2, -height/2, width/2, height/2);
What's wrong? path is an FSShapeConstructor instance, and FSShapeConstructor does have a method named ellipse - ok, one "l" missing! Now the error is gone.
Eclipse 3.1 reports 143 warnings, all of them caused by unused members or local variables, so nothing serious. I'll remove them later

Let's explore the code structure.
The API itself, Transform, consists of a single package, com.flagstone.transform. Is this good or bad?
In my opinion, Flagstone developers went the easiest way here, not having to worry about inter-package access.
But what about the API users? They get a package containing 114 classes, 113 of them starting with "FS", I guess that's supposed to mean FlagStone. It seems pretty difficult to me to find my way through, mainly because I can't make up the difference between tags, actions and other records at first glance. At least a package for the tags and one for the other records would be of great help.
Currently I have to say that I have no idea how to use the API

Ok, let's read some docs

Ralf

Reading Docs (Mostly) Helps
I was pleased to find out that the API is pretty well commented. Each class has a Javadoc header containing a description of the class, examples and a history section containing a description of the class equivalent in the Flash specification. I think especially the last section is important, as some classes (representing tags, but also other records) are named differently than the tags you find in the specification. Personally, I would have liked a little more consistency here, but if you start from scratch with Transform without having worked with the specification, that won't make too much difference to you. However, if you try to create some sophisticated Flash content using such a low-level API like Transform, there is no way around working with the specification.
It turns out that the FSMovie class is the answer to most of my questions. It can be used to parse as well as generate SWF files. I expected some class like "SWFParser" or "SWFWriter", but I guess that's a matter of taste.
Ok, so let's try to parse a SWF. I have a big collection of SWF files which I use to test JSwiff, so let's try it out... I wrote a tiny java program that reads SWFs from a directory and writes them to another. Basically, the following function is called for every file within the directory:

Code:

 private static void copy(String sourceFile, String destinationFile)
   throws DataFormatException, IOException {
   FSMovie movie = new FSMovie(source);
   movie.encodeToFile(destination);
 }

I tested this with my SWF collection, and finally, after about 90 files, I got the following exception:

Code:

java.io.IOException: Movie object did not decode correctly.

although the source SWF file is perfectly valid. I'm not impressed...

Ralf

More Problems...
Now let's examine the files Transform managed to copy using the procedure explained above. The first 2-3 files were perfect, but then - wait! What are those red rectangles? It seems that in some cases bitmaps are replaced with red rectangles. This is no individual case, this happened in about 60% of the cases (55 of 93 files).
The other files seemed to be ok. But after thorough examination I found another error. In the source movie, when moving the mouse pointer onto a button, the button looks as if it were pressed down (lowered). This doesn't change until the pointer is moved away:

In the movie generated by Transform, the button is pressed only for a short moment, and then it is released, so the hover (or rollover) effect is gone:

In both screenshot snippets, the mouse cursor points at the "our team" menu entry. You can also see how some bitmaps are replaced with red rectangles.
If you want to manipulate Flash movies with Transform, you'll likely lose bitmaps and hover effects. To me, this is unacceptable. Especially for the bitmap problem there's no excuse, as such a primitive testing procedure like this would have revealed the problem. I suppose that if you create a movie from scratch, you will run into the same problems. Personally (and this is subjective), I wouldn't rely on an API that is obviously not tested thoroughly enough.

Ralf

To a Higher Level
Transform is, like JSwiff's API, a low-level API both for creation and parsing of Flash files. It can be pretty cumbersome to create shapes or fonts with the low-level API. Flagstone additionally provides some higher level classes to make movie creation easier. The package com.flagstone.transform.util contains six classes, of which four sound interesting to me: FSImageConstructor, FSShapeConstructor, FSSoundConstructor and FSTextConstructor. So let's see what this classes are able to do.
I know that text construction and font creation can be a tedious task when working at tag level, so the first thing I was interested in was an example provided by Flagstone named ShowAWTFonts, which is supposed to show how FSTextConstructor can be used to generate SWF fonts, using AWT fonts. That sounded really good, but when I started the example I was a little disappointed, as it got stuck in an endless loop. It turns out that I cannot read

I passed the output directory as command line parameter without specifying "--resultDir" in front of it... ok, after a while, the output directory seemed to contain some files, for each font one SWF, e.g. Arial.swf. The files really contained text using the corresponding font. Too bad the letters were somehow superposed, I guess the text doesn't move to the next line after reaching the end of the current line, it just starts over at the left of the current line. Nevertheless, I liked the result, as Arial italic seemed to be really italic, and just as well, Arial bold was bold. Comparing the fonts from the created SWFs with their representation in Windows (in the control panel), I found out that the fonts were correct, they also looked good after reapeated zoom-ins.
Too bad the program got stuck again in an endless loop while processing the "Academy Engraved LET Plain" font - what can I say, I didn't even know I had such a font on my machine. However, I still was a little disappointed, even though the font creation somewhat impressed me.
The next thing I tried out was the ShowImage example, which can import PNG, JPEG or BMP images and generate SWFs containing them. PNG worked like a charm, but JPEG didn't. Instead of the picture, only a red rectangle. These red rectangles again! I expected them to appear again, but not so soon... 4 bit and 8 bit BMPs were handled well, but 24 bit BMP images produced only white (empty) movies. A bitter aftertaste again... I experienced something similar with the BasicSounds example, which is supposed to be able to import WAV and MP3 sound files. WAV and 128KBit MP3 files worked, but 192KBit MP3 files always sent Transform into an endless loop. I just got an email from the OSFlash mailing list, there seems to be a fix for this problem, which is supposedly caused by a missing eof check.
The BasicShapes example worked flawlessly, it generated a small SWF movie containing an animation of some shapes (rectangle, ellipse, circle, cross etc.)

Ralf

A First Conclusion
After some superficial tests, I came to the conclusion that the Transform API offers a lot of pretty cool features. I have to admit that with this respect, JSwiff lags behind up to now. In the current version, JSwiff doesn't offer high level movie creation classes, only tag level read and write access, it neither has an ActionScript compiler like Translate (which I didn't manage to test yet).
What really bothered me was the fact that Translate is far from being thoroughly tested, although it was a commercial product for years. I really don't understand Flagstone's versioning policy, as version 2.0.3 implies that once there was a stable, relatively bug-free version 1.0. Ok, part of the bugs I encountered are probably in the extension part for high level movie creation, but it's obvious that some elementary features are buggy (see above - red rectangles, rollover effects). Moreover, to me, Transform seems abandoned on the part of Flagstone.
JSwiff will provide with its version 1.0 a stable low-level API, as this is the foundation for all features to come. Although its license (GPL/commercial) is more restrictive than the BSD license Transform is offered under, it assures the project's progress, but it also encourages projects based on JSwiff to remain free and open source.
It is laudable that Transform is available under a BSD license which allows you to use it in your commercial applications for free - if you have faith in its stability, which, after this short evaluation, I cannot.
Describe, a tool for SWF file exploration (similar to JSwiff Investigator), which in my opinion is an indispensable tool when working at this level, is a commercial product. I would have liked it to be free, too.
Another disturbing point is that the Transform project seems to stagnate. There weren't any noteworthy feature enhancements after the release of the first open source version. To me, Flagstone developers seem to have abandoned Transform a long time ago. In contrast, JSwiff is continuously extended. JSwiff 1.1 will offer XML support (generation, parsing and XML schema), as well as some high-level features for movie creation, similar to the util classes in Transform. As of this writing, I have partially developed some new features supporting translation between SWF and XML, you can find the new features in the jswiff-xml Subversion branch.
In a further version, a compiler for a language similar to Java will be included, as a replacement to ActionScript. You may wonder why. JSwiff is targeted at Java developers, and Java developers want to code in Java. Being a subset of Java, the new language will be much easier for them to work with than to learn a completely new language like ActionScript.
The integration into Eclipse will be the final step in the development of JSwiff - and the biggest challenge.
OK, now I expect some comments from you!