DISCLAIMER: I'm posting this as a reference to myself and others. It's a very specific testcase of using ATF compressed textures in Starling. I don't claim to understand all the texture compression details or options, these are just my observations. Your use-case is different and your mileage may vary.
Reading about Adobe Texture Format (ATF), there are two main reasons to use it - compressed textures are smaller and will use less GPU memory, and they can be uploaded to Stage3D asynchronously.
On an iPad 2 device, using a 2048x2048 PNG source texture, disabling mipmaps with the -e option, and using scout to determine time/memory values (and a debug build, of course):
Observation 1 : Using a Loader to load the PNG, then Image.fromBitmap(loader.content), the UI locks for 3.5 seconds (while it decodes the PNG, generates mipmaps, and uploads the texture), and it uses 25MB of GPU memory
The result is the same if you use an [embedded] PNG image.
Observation 1.5 : Using a Loader to load the PNG, with ImageDecodingPolicy.ON_LOAD, then Image.fromBitmap(loader.content, false) (to skip mipmap generation), the UI locks for 0.37 seconds while the texture is uploading, and it uses 25MB of GPU memory
Observation 2 : Using a File to load an ATF texture bytes of uncompressed RGB data (perfect quality), then Texture.fromATFBytes using async loading, the UI locks for 0.3 seconds and it uses 25MB of GPU memory
png2atf -e -i atlas.png -o atlas_rgb.atf
TODO: I'm surprised that ATF "async" doesn't yield more of a speed benefit compared to observation 1.5 (0.3 sec vs 0.37 sec). I should try this comparison again uploading multiple atlases.
Observation 3 : Using a File to load an ATF texture bytes of compressed PVRTC data (moderate quality), then Texture.fromATFBytes using async loading, the UI locks for 0.05 seconds (almost imperceptible) and it uses 6.5MB of GPU memory
png2atf -c p -r -e -i atlas.png -o atlas_ios_cpr.atf
Observation 4 : Playing with other compression options (422 color space, quantization levels) yielded even less UI locking, but didn't reduce GPU memory usage, and the quality is absolutely hideous. These options are basically unusable, imo. The basic PVRTC quality is decent, but DXT5 and ETC1 are pretty bad, too. I hope the Android version isn't too ugly.
png2atf -c p -r -q 1 -2 -e -i atlas.png -o atlas_ios_cpr_q1_422.atf
The morals of the story:
Guideline 1 : When loading PNG Textures into Starling with a Loader, always use ImageDecodingPolicy.ON_LOAD so that the PNG decode (600 ms in my case) happens in the background Loader thread.
Guideline 1.5 : Mipmaps are expensive. Decide for yourself if you need them, and be aware of the options. If you do, using ATF to generate mipmaps ahead of time is a good option, as generating mipmaps at upload-time required 2.5 seconds in my observation 1 above.
Guideline 2 : If you can live with the reduced quality, use device-specific compression (PVRTC, DXT5, ETC1) in two cases: 1) on low-end devices with limited memory, or 2) when the fastest upload speeds and minimal UI locking are necessary.
Do use the JPEGXR -r flag to losslessly compress your device-specific ATF files. They'll be smaller files to package and load from disk (though use the same amount of GPU memory). The default quant level is 0 (lossless) for these block compressed (device-specific) atf files.
Question: Are there options for improving the quality of these block-compressed formats from the defaults?
Guideline 3 : You can play with other compression options (422, quant), but they result in ugly textures and color glitches (too ugly for 2D, imo) and the same overall memory usage, reducing only filesize and upload time.
Note : If you use ATF, unfortunately this means must use a compile-time asset workflow because there is no runtime ATF compression. (Though I wonder if it's possible to hack an uncompressed RGB888 ATF file at runtime just for the async upload capabilities. Hmm, new project time! =D)
Feel free to disagree, discuss, or post your own findings. If you prove me technically wrong on any points, I'll be happy to update the above.
The below images are encoded using:
PVRTC + JPEG XR Q0 (lossless) (-c p -r)
PVRTC + JPEG XR Q1 (lossy) + 422 (-c p -r -q 1 -4)
Update, Dec 5, 2013: Best quality PVR
Since this post has been useful to some, I'll add another tidbit. The best quality PVR compression I've found for iOS is attained using the PVRTexTool utility from PowerVR. I think you have to sign up for their developer program to download the PowerVR GraphicsSDK, but it's free, though maybe you can find the tool itself elsewhere. Anyway, this commandline gives better PVR compression quality than Adobe's tool*:
PVRTexToolCL -i atlas.png -o atlas.pvr -m -l -f PVRTC1_4 -q pvrtcbest -mfilter cubic
This creates a .pvr file, and you then use Adobe's pvr2atf to create the atf file:
pvr2atf -p atlas.pvr -o atlas.atf
* - this is interesting, since it seems that Adobe's tool (png2atf) uses PVRTexTool libraries under the hood (same stdout while encoding). PVRTexTool also has more options for quality and encoding - play around with them in the GUI, but the above setting represents the best quality (albeit fairly slow to encode) for iOS compatibility.