ATF ETC2 Format texture does not work on some Android devices

[hardcoremore]

When compiling with AIR SDK 27 ATF textures that include ETC2 only compression format will not display at all on some Android devices. On iOS everything is working fine.

I am using latest Starling 2.2

Currently ETC2 textures will not display on following Android devices:

Samsung s6 Edge.
Huawei P10 Lite
Samsung Glaxy Tab 3.

However ETC2 textures will be displayed on the following Android devices:

ZTE Blade A910 with Android 6

[mistergreen]

ETC2 doesn't display on using AIR/starling
Samsung Galaxy Tab 3, Vivante GC1000 GPU

I made a quick Unity apk with images with ETC2 compression. This works on the android device from above.
One is an image of a guy and some pipes.
https://adobe.ly/2As9ApC

[mistergreen]

Here's an AIR 22 apk
https://adobe.ly/2ANWaoF

The ETC2 does not show up on the device but does show on the simulator.

[PrimaryFeather]

Further tests indicate that there's something wrong in many cases when using ETC2.

Here is a zip file with ATF textures using ETC2 exclusively, with and without alpha channel / with and without mipmaps: atf-etc2-samples.zip

The file also contains

• the original PNG files
• the command line arguments used to create the ATF files
• a Starling class that attempts to display those textures.
• All tests were done with AIR 27.

The outcome:

• starling-etc2.atf throws: Error #3677: Texture decoding failed. Internal error. everywhere (simulator, iOS, Android).
• An old Nexus 7 (2012, Android 4.3) displays none of the textures.
• A ZTE Blade A910 with Android 6.0 displays only the textures without alpha.
• Flash Player Projector (on macOS) showed only the texture with alpha
• An iPhone 6S with iOS 11.2 displays everything (except the one with error 3677)

[hardcoremore]

Awesome work Daniel.

I think we now have more than enough data to submit proper bug to the Adobe.

[PrimaryFeather]

Indeed! I'm already in contact with Adobe about this issue. 😄

[gsario]

Guys, any news about this issue?
ETC2 is so mainstream standard that it should be a very high prio for Adobe to fix it.

[hardcoremore]

Daniel said that Adobe is working on this and that they are making progress. I would also like to see this be fixed. Also I wish they fix bug with hidden string allocations on iOS when assigning Vectors to Object or Dictionary Bug Report. Please vote if you haven't already

[PrimaryFeather]

I started another inquiry about the progress — will post here when I know more!

[hardcoremore]

Sorry Daniel I do not understand. What does it mean that you started another inquiry? Does it mean that you are investigating the issue by yourself or that you have another conversation with Adobe about the progress.

Thanks

[PrimaryFeather]

What I meant was simply to write them an email and ask for the latest status. 😉
And they already got back to me and said they will have something for us to test really soon.

[hardcoremore]

Wow awesome. I hope they fix all the issues. We are so close to have a really solid AIR SDK that works good for Android and iOS just need a little more polishing and bug fixes :)

[PrimaryFeather]

AIR 30 should fix most of these problems! ✨

ETC2 textures now load fine in my tests, if you follow a few rules:

• Don't use the "-r" flag in png2atf for now (that's JPEG-XR+LZMA compression). It sometimes produces artifacts on Android.
• Beware that ETC2 textures without alpha are currently not displayed in the adl simulator.

Furthermore, it's important to know how this was implemented by Adobe:

1. Older devices (OpenGLES 2.0) which don’t support ETC2 , will continue to have hardware rendering of ETC1 textures.
2. Newer devices (OpenGLES 3.0) will continue to have hardware rendering of ETC2 textures.
   If only ETC1 textures are provided for newer devices, we use software rendering (Software decompression to convert ETC1 to 32 bit RGBA texture).

In other words: new devices (with OpenGL ES 3 support) will use software decoding for ETC1 textures. Thus, my recommendation for Android is to always bundle ETC1+2 together in the ATF textures for Android.

I think all those limitations are not really problematic — what's important is that ETC2 textures are now finally really usable on Android!

Please, anyone, give this a try and let me know how it goes. 😄

[gsario]

@PrimaryFeather this is what i see in release notes for AIR SDK 30

Known Issues
AIR

• ETC2 with Alpha content having LZMA/JPEG-XR compressions have black dots/lines when rendered on Android
• ETC2 Non Alpha ATF are not rendered in ADL
• StageWebView is not able to load punycoded URLs

1. Does your comment about "-r" flag fix the mentioned artifact issue?
2. In TexturePacker to avoid JPEG-XR+LZMA is it enough to not select JXR compression?
3. Furthermore, does anyone know how to read Android's OpenGL version?

[gsario]

@PrimaryFeather, thanks for your response!
We have some questions that you might be able to help with...

1. Where did you find the info about software/hardware decoding modes of ETC1/2 based on OpenGL version?
2. Was this approach implemented in AIR SDK 30, or in earlier versions as well? This is important for us as we have all our sprite-sheets in ETC1 currently, and the way you described it means our sprite-sheets were software decoded all this time on new OpenGL 3.0 supporting devices!
3. Another problem is that having ETC1 + ETC2 without JRX-LZMA really bloats the size of the app. And looks like this is the only option now! Adobe team needs to know that this limitations are creating very big issues for developers.
4. How we can read Android device's supported OpenGL version?

[PrimaryFeather]

I answered some of the questions in detail here, but I'll repeat it here, for reference:

1. I tested this feature for Adobe with a pre-release version; that's when they told me about these limitations. Somehow, they must have forgotten to update the documentation.
2. This only applies to AIR 30 and later.
3. Adobe is aware of this, and they hope to provide a fixed "-r" implementation soon.
4. All mobile devices (iOS + Android) that run in "standard extended" or higher have OpenGL ES 3 support and will support ETC2 textures. So if you start Starling in "auto" profile, you can simply check the profile that was used (via starling.profile) and thus, if ETC2 is supported.

I hope that helps!

[hardcoremore]

I have tested ETC2 on Android with my game and everything seams to be fine. So I am now using ETC2 only and without JRX. I do not know what is JRX? Should I use that?

[gsario]

@hardcoremore, ETC2 + JRX has known issue on Android with AIR SDK 30. When Adobe fixes it, you should use it, as it keeps the textures compressed, thus the size of ATF is much smaller. When you create your APK it gets to the same size as the same compression is applied on all files added into APK. But when the app is installed APK is unarchived, means your textures can become 100MB on the device instead of being 15MB with JRX compression.

[PrimaryFeather]

One more thing: apparently, JRX does work for textures without alpha. So for a specific type of images (e.g. background images or photos), you can safely enable JPEG/XR.

I tested this on an Android phone that does show the artifacts for alpha textures; and it was mentioned in the email I got from Adobe (but I only noticed that just now).

[gsario]

Thanks for letting us know @PrimaryFeather! But We expect Adobe to fix this asap in next, hopefully coming soon SDK version.

[hardcoremore]

In today's release AIR 31.0.0.85 Adobe fixed:

ETC2 Non Alpha ATF are not rendered in ADL (FLASH-4190225)

[PrimaryFeather]

Ah, that's great news! Downloading AIR 31 now — I'll test if I can confirm the fix and will report back.

[PrimaryFeather]

[Forget my previous message. I thought they'd fixed the JXR issue, but it's just about ADL.]

[PrimaryFeather]

Yes, the ADL issue is fixed! 😄

JXR compression still doesn't go well with transparency, but that's another story.

[rainbowcreatures]

Found out about this only now just before release :( @PrimaryFeather did you mean to detect "Standard" and above or "Standard Extended" to use ETC2 safely? (On another forum post you wrote: Actually, I had expected that any device supporting "Standard" or above would support ETC2. 🙁 ).

[PrimaryFeather]

Here's the code I'm using to detect the best supported compressed texture format:

private static function getOptimalAtfFormat():String
{
    var fallbackFormat:String = SystemUtil.isIOS ? "pvrtc" : "etc";
    var currentProfile:String = Starling.painter.profile;
    var profilesNotSupportingEtc2:Array = [
        "standard", "standardConstrained",
        "baselineExtended", "baseline", "baselineConstrained"];

    return profilesNotSupportingEtc2.indexOf(currentProfile) < 0 ? "etc2" : fallbackFormat;
}

However, you don't necessarily need to use PVRTC, because "etc" also works well on all iPhones. However, PVRTC yielded a little better image quality in my tests.

Also, don't forget that for transparency, you cannot use JXR compression in ETC2 — or at least you couldn't when I last tested it, maybe they fixed that in the meantime! A quick test with the latest AIR version will verify this.

I hope that helps!!

[rainbowcreatures]

Thanks @PrimaryFeather ! That was insanely fast response, and on Easter :D Ok so I should go for Standard Extended for ETC2 looking at your source? It is a tiny bit confusing because in a cached Adobe doc I found they write this:

Mobile platform

"The “Standard” profile requires OpenGL ES 3.0 on mobile platform. Nowadays, there are many high-end smartphones and tablets that have support for OpenGL ES3.0, (iPhone 5S, iPad Air, Samsung S5, Samsung Note3, etc.)".

Which would imply that Standard is always OpenGL ES 3.0 and ES 3.0 should support ETC2? Or is it really just "standard extended"?

I'm targeting Android only with this build, so I can ignore PVRTC I think?

And yep I'm aware about that whole JXR +transparency :/ All of my atf's have transparency, so I'm going for uncompressed ETC2 + JXR/LZMA compressed ETC1, bundled in separate ATF files. That seemed like a good compromise, saw you suggesting it elsewhere.

[PrimaryFeather]

Yes, it's quite confusing from looking at the docs, I had the exact same problem. 😉

So I specifically asked someone from Adobe and got this response:

Open GL ES 3.0 mobile devices will support standard extended profile and Open GL ES 3.0 devices support ETC2 codecs.  So, your assumption is correct.

So that explains it: when OpenGL ES 3 is supported, Stage3D runs in "Standard Extended", and then ETC2 support is guaranteed.

All the best, and happy Easter! 😄

[rainbowcreatures]

Thanks, its all clear now! Happy Easter ! :D

[llorenzo]

So, the combination of ETC2 and JXR + A it is still an issue on Android. The AIR implementation of JXR decompression of ETC2 must have some fault. It is a huge drawback on highly graphic intensive apps. My current project ( graphic novel ) needs that fixed. please.

[ajwfrost]

Hi @llorenzo - I've only just seen this issue and have just read through it. Would it be possible to get a test case for this ETC/JXR/Alpha issue?

I know from experience that the ATF handling within AIR is insanely convoluted due to the masses of different combinations and permutations of formats that are available and may be supported, but this may be something we can look into ..

thanks

[llorenzo]

Hi Andrew, thanks for coming by. All I know is from this and other threads in the Starling Forum. It has been reported by Daniel and others and there is no official fix reported. For what I understand, it happens on some Devices. https://forum.starling-framework.org/d/19374-atf-png2atf-with-texture-compression-r-is-unusable-on-some-android-devices
For projects with a lot of graphics ( eg. graphic novel ) it is of course essential to compress the ATFs.