Good news everyone. The Apparat inline expansion works now to full extent after fixing some minor bugs. A complete example is also available. Just change the paths in the build.properties file and compile everything using Ant.
Use the inline feature with care. Apparat does not try to optimize your code and performs nothing but dead simple inlining. This can lead to slower code due to the creation of lots of local registers. Your code gets also much bigger and will require more space in memory. I am actually not a fan of manual inlining at all. I think it makes only sense to inline code if you have a powerful optimizer available that will cleanup the whole mess.
The fun story about this example is that the inlined version is slower using the lastes Flash Player release candidate if you have only 40.000 particles. That is why I increased the number of particles to 80.000 ;). I developed the example using an old standalone player and the inlined version was nearly twice as fast. However when I watched the example in the browser with the latest release candidate the game was completely different. Kudos to Adobe for significantly improving the Flash Player performance!
Good news everyone. The Apparat inline expansion works now to full extent after fixing some minor bugs. A complete example is also available. Just change the paths in the build.properties file and compile everything using Ant.
Use the inline feature with care. Apparat does not try to optimize your code and performs nothing but dead simple inlining. This can lead to slower code due to the creation of lots of local registers. Your code gets also much bigger and will require more space in memory. I am actually not a fan of manual inlining at all. I think it makes only sense to inline code if you have a powerful optimizer available that will cleanup the whole mess.
The fun story about this example is that the inlined version is slower using the lastes Flash Player release candidate if you have only 40.000 particles. That is why I increased the number of particles to 80.000 ;). I developed the example using an old standalone player and the inlined version was nearly twice as fast. However when I watched the
In addition to macro expansion Apparat has now inline expansion as well. It works nearly the same way as macro expansion but without most of its limitations. To define a class for inline usage it must extend apparat.inline.Inlined and all its methods must be static. However the cool thing is that you can also return values in contrast to macro expansion. You can also pass normal parameters. For instance FastMath.sin(FastMath.sqrt(2.0)) is valid code using inline expansion. It is enabled by default in TDSI.
In addition to macro expansion Apparat has now inline expansion as well. It works nearly the same way as macro expansion but without most of its limitations. To define a class for inline usage it must extend apparat.inline.Inlined and all its methods must be static. However the cool thing is that you can also return values in contrast to macro expansion. You can also pass normal parameters. For instance FastMath.sin(FastMath.sqrt(2.0)) is valid code using inline expansion. It is enabled by default in TDSI.
Apparat has a great new feature that allows you to create even smaller files. Basic SWF files are compressed using Java’s standard java.util.zip.Deflater class. This is perfectly fine. And I would even go with no compression at all during development.
However when deploying you can spend some extra time compressing your SWF files with the best tools available. 7-Zip is for instance such a tool and achieves a great compression ratio.
If you have the 7z executable on your PATH Apparat will make use of it to achieve the best compression for your SWF files. More configuration options are available here.
This feature is currently only implemented for SWF files and not SWCs. However every tool will make use of it by default. So if you are running Reducer and have no graphics in your SWF files you can still get a better compression.
An example is straight from the sources:
reducer -i as3\Apparat.Tests.AS3\bin\Test07.swf
[i] Apparat -- http://apparat.googlecode.com/
[i] Launching tool: Reducer
[i] Waiting for 7z ...
[i] Compression ratio: 18.224573%
[i] Total bytes: 310
[i] Completed in 547ms.
Note please that this SWF file does not contain any graphical assets and we got still a ratio of 18%. Our main audiotool.swf file is compressed by about 10% — about 200kb — and contains no graphical assets either.
You can download the latest Apparat on Google Code. Please note that you will need Scala 2.8 RC1 as well.
Apparat has a great new feature that allows you to create even smaller files. Basic SWF files are compressed using Java's standard java.util.zip.Deflater class. This is perfectly fine. And I would even go with no compression at all during development.
However when deploying you can spend some extra time compressing your SWF files with the best tools available. 7-Zip is for instance such a tool and achieves a great compression ratio.
If you have the 7z executable on your PATH Apparat will make use of it to achieve the best compression for your SWF files. More configuration options are available here.
This feature is currently only implemented for SWF files and not SWCs. However every tool will make use of it by default. So if you are running Reducer and have no graphics in your SWF files you can still get a better compression.
An example is straight from the sources:
reducer -i as3\Apparat.Tests.AS3\bin\Test07.swf
[i] Apparat -- http://apparat.googlecode.com/
[i] Launching tool: Reducer
[i] W
The TAAS compiler is different from the ActionScript compiler since its input is not ActionScript source code but already compiled SWF or SWC files. Just like the haXe compiler can output AS3 instead of a SWF the TAAS compiler can do the same.
Now if you add one and one together you see that the TAAS compiler can be used as a very strong decompiler. My own tests have shown that it will work flawlessly where other commercial decompilers output rubbish. Since the compiler behaves like the Flash Player it will “execute” the bytecode in order to parse it which means it has a very highlevel understanding of the structure inside the SWF.
The only question is now what to do with the source code. I wrote the decompiler for my session at FOTB to show much easier how the optimizations behave. It is also a great tool to debug errors. But should it be opened or not?
To take it one step further one might also be able to write an obfuscator using the TAAS compiler. In my opinion it would be cool to have a strong decompiler and obfuscator, both being open source. We might also add an option to protect SWFs from the decompiler by adding something to the SWF metadata for instance. Of course this is just a simple rule which could be removed by someone once the code is open. What do you think?
The TAAS compiler is different from the ActionScript compiler since its input is not ActionScript source code but already compiled SWF or SWC files. Just like the haXe compiler can output AS3 instead of a SWF the TAAS compiler can do the same.
Now if you add one and one together you see that the TAAS compiler can be used as a very strong decompiler. My own tests have shown that it will work flawlessly where other commercial decompilers output rubbish. Since the compiler behaves like the Flash Player it will "execute" the bytecode in order to parse it which means it has a very highlevel understanding of the structure inside the SWF.
The only question is now what to do with the source code. I wrote the decompiler for my session at FOTB to show much easier how the optimizations behave. It is also a great tool to debug errors. But should it be opened or not?
To take it one step further one might also be able to write an obfuscator using the TAAS compiler. In my opinion it would be cool to have a strong d
Dump has now another cool feature: UML diagram generation. The UML diagram is exported in DOT format. I think this is a really cool feature because the graph is built by analyzing a SWF file and you get it for free. I will probably create a different tool to make full use of the UML generation since you could link multiple files together for a complete coverage. Since Graphviz is not able to underline text I have choosen to use a dollar sign for static methods. You will also get proper parameter names if you compile your SWF file in debug mode.
This is an example UML diagram for the playerglobal.swc. In order to create it I took the playerglobal.abc from the Tamarin sources and the command was java -jar dump.jar -input playerglobal.abc -uml.
Here are two example representations but be careful. The PNG size is 30831×6232 and might crash your browser. Chrome can display the PNG for me but is not able to show the SVG correct. Firefox displays the SVG very well. You can download the PNG and open it in IrfanView or Photoshop to be safe.
Dump has now another cool feature: UML diagram generation. The UML diagram is exported in DOT format. I think this is a really cool feature because the graph is built by analyzing a SWF file and you get it for free. I will probably create a different tool to make full use of the UML generation since you could link multiple files together for a complete coverage. Since Graphviz is not able to underline text I have choosen to use a dollar sign for static methods. You will also get proper parameter names if you compile your SWF file in debug mode.
This is an example UML diagram for the playerglobal.swc. In order to create it I took the playerglobal.abc from the Tamarin sources and the command was java -jar dump.jar -input playerglobal.abc -uml.
Here are two example representations but be careful. The PNG size is 30831x6232 and might crash your browser. Chrome can display the PNG for me but is not able to show the SVG correct. Firefox displays the SVG very well. You can download the PNG and open it in Irf
