Yup, the current Adobe Flash Player Incubator builds have more stuff to talk about. We are consistently looking at keeping the Flash run time up to date with current technologies. And as I said in my previous post bandwidth and storage space still matter for most developers and users. So going forward are looking at extending the current compression mechanism for SWF files which is based on zlib today to support LZMA compression also. We have been using LZMA for several years now in our installers. And like for JPEG XR, LZMA became a requirement for Molehill textures. The step support it for SWFs was a small one from here.

LZMA was originally created by Igor Pavlov who has since then placed the entire code base into the public domain. It beats zlib compression by a wide margin. Though it is much better the incremental improvements very much depend on the type of content you have in your SWF file. In general the more ActionScript code and vector graphics (and now 3D meshes) you have in your SWF the better the improvements will be. It will not do much better if your SWFs mainly consist of bitmaps. Let me put out some numbers here:

Igor Pavlov
zlib LZMA Gain/Loss
Mandreel NyxQuest 14,296,699 bytes 8,892,786 bytes -37.8%
Flex 4.5 RSLs (combined) 3,091,229 bytes 2,357,002 bytes -23.8%
CopperCube Molehill Backyard Demo 5,530,215 bytes 4,890,509 bytes -11.6%
Away3D LoaderOBJTest 3,921,994 bytes 3,754,181 bytes -4.3%
Mario Forever Flash 2,779,142 bytes 2,735,930 bytes -1.6%

What about ByteArray.compress()/ByteArray.uncompress() support for LZMA? Not yet, that is a little more complicated.

So how can you try this out? Well, this is so fresh we don’t have tools available yet. Though you could whip up a python script which does that in about 10 lines of code. Since I am not a python buff, I whipped up a few lines of C++ code to do this instead :-) Feel free to try this out if you are adventurous and let me know if it makes a difference for you.

And as a reminder: all these features which are part of Incubator are experimental and not committed any final release, we are are really only looking for early customer feedback.

[Update: Looks like Burak Kalayci and Joa Ebert already found a bug in my sample code. This is if course the reason we have Incubator builds: to catch these things early. I'll be updating this code when the next Incubator build goes out. Keep the feedback coming!]

Leave a comment


  1. compress my as3 lib ,lzma:615k zlib:722k
    i implemented an as3 decoder and spent 10 sencod to decode my lib,i dont think alchemy would helps alot,native lzma is a must,async operation would be great

  2. Neat. The more common formats supported, the better. I really hope the final version will bring support for LZMA in code.

    Also, I think it is worth mentioning that although LZMA offers better compression ratios, it’s also commonly way slower than zlib. It would be nice to see a benchmark of how both implementations compare in Flash.

    About async operations… threading would be great, and it’s about d*mn time to add it. I read after MIX 2010 that it’s already being looked into, but the player team wants the API model to be as easy as possible, allowing developers not to care (or at least the less possible) about synchronization primitives.

  3. Personally I would love a faster compression rather than smaller output. I also don’t know if compilation size nearly as important as ByteArray.compress which is currently very slow.

    In terms of async calls, that would also be cool but I feel like every method that is slow like this should have options for async or not. Async calls make your code far more complicated and in situations that need to be synchronous it’s just annoying to have to write all of that extra code.

    Thanks for the news on LZMA it’s awesome to have options.