crash with ADL from the AIR SDK

[neolit123]

hello, i'm trying to use PNGEncoder2 from AS3.

i have tried both the provided SWC and compiling one with haxe 3.1.3.
using amxmlc from the AIR SDK 16 / 17 to compile the AS3 project.

PNGEncoder2 related usage is in the lines of:

import PNGEncoder2;
...
var png:ByteArray = PNGEncoder2.encode(bmp);

running the compiled app from ADL(.exe) results in a crash in Adobe AIR.dll for AIR SDK 16, and an infinite loop from AIR SDK 17.

the strange part is when i grab the same BitmapData and load it in a simple Test.as project with EMBED, recreate the same folder structure as the problematic project, and don't add anything else, it works fine.

any ideas what might be causing that? compiler issues, perhaps?

EDIT: after some more testing, apparently i have made an error above. it works with AIR SDK 17, but crashes AIR SDK 16.

[neolit123]

so here is a test project that crashes the AIR SDK v16:
https://dl.dropboxusercontent.com/u/1627980/github/test-PNGEncoder2.zip

you can download the v16 SDK from here:
https://helpx.adobe.com/air/kb/archived-air-sdk-version.html

the good part is that v17 works, yet not everyone has transitioned to v17 because it's a bit buggy.

[cameron314]

Yep, you're actually the second person to bring this to my attention (just the first to do it publicly).

I'm really sorry, but I don't think there's anything I can do about it. PNGEncoder2 relies on Alchemy opcodes, support for which was apparently broken in version 16 of the AIR SDK (but reportedly working in 17).

The only way I can see around this would be to look at the equivalent opcodes generated by crossbridge (which apparently still works with SDK 16), and hack the HaXe compiler to emit those opcodes instead (actually, it would probably be a good idea to figure out what the problem opcodes are first). And that's assuming that the opcodes themselves are causing the problem, and not some other HaXe incompatibility (although I don't see lots of HaXe users having general compatibility problems, so it probably really is the opcodes).

I don't have time to do this myself, but if you're feeling gung-ho I could help with any questions you might have re the encoder.

[neolit123]

my on-the-spot solution is to check the version of the AIR runtime (at runtime) and fall back to PNGEncoder.as from Adobe (almost 8 times slower in my tests with the built-in zlib deflate).

they could have at least exposed some of the ZLIB properties via the ByteArray API.

thanks for the reply and for the work on this fast encoder. :)
i now include it as optional in this tiny tool for Starling:
https://github.com/neolit123/ta-gen

credit is given.

[cameron314]

Cool, I'm glad it's still useful :-)
I wonder, how's the compression compared to the original PNGEncoder?

[neolit123]

that's a good question because i didn't check the sizes up until now.

(the test bitmap is from the above zip file i've posted)

PNGEncoder2 (default options), ~600kb, ~121ms
PNGEncoder.as (ByteArray.compress()), ~180kb , ~900ms
BitmapData.encode() with "fast" for the PNGEncoderOptions, ~300kb, ~40ms
BitmapData.encode() without "fast" for the PNGEncoderOptions, ~180kb, ~1200ms, 

so actually the built-in BitmapData.encode() with fast has the nicest tradeoff for this particular image.
hm...i probably should add a toggle for the user to make a pick.

[cameron314]

Interesting, thanks for the info (I don't currently have a setup to compile any flash-related stuff).

You know, I just remembered that I already did a bit of analysis comparing PNGEncoder2 to BitmapData.encode if you're curious.