Open marpies opened 7 years ago
Thanks a lot for the heads-up!
I just tried your sample with an ZTE Blade A910 running Android 6.0, where I could not reproduce it; however, on an 2012 Nexus 7, the app stops after just a handful of images (no more than 10). You are right, this is a critical problem, especially since the AssetManager now loads textures asynchronously per default. Maybe I need to make this optional instead — depending on what Adobe manages to do about it.
In any case, I voted for the issue! Please keep me updated if you find out anything new. Thanks in advance! :smile:
Thanks for checking it out, Daniel. I'll keep you updated on the progress.
Just a quick question - what Android version is your 2012 Nexus running? Thanks!
Ah, sorry, totally forgot to mention that. That one's still running Android 4.3!
I couldn't reproduce the issue on Nexus 5X with Android 7.1.1.
I used the precompiled apk.
Thanks for testing it out @randalfien.
Here's a list of devices that have been tested so far:
Nexus 5X (7.1.1) – OK Samsung SM-G550T (6.0.1) – OK Samsung SM-N9005 (5.0) – OK Samsung GT-I9300 (4.3) – OK Samsung GT-P5100 (4.2.2) – OK ZTE Blade A910 (6.0) - OK
Nexus 7 2012 (4.3) - FAIL Nexus 7 2013 (6.0.1) - FAIL Sony Xperia Z3 (6.0.1) - FAIL
Have you recently tried this again, @marpies?
I just looked into it again, and I couldn't reproduce it with the latest AIR 27 version — however, I also failed to reproduce it with the old AIR 25 today, on the same Nexus device as in March. Which is really strange.
For reference: with the current Starling version, you have to add the following code so that Starling even attempts to load the texture asynchronously:
Texture.asyncBitmapUploadEnabled = true;
I did that, and the async methods are definitely called. Still, no luck in reproducing it today. However, in the "Adobe Tracker" report, there hasn't been much going on either, so I suppose nothing changed yet.
@PrimaryFeather Yes, unfortunately I'm still able to reproduce it with the latest Starling and AIR 27. Sometimes it takes a while to occur, but seems to happen every time on the aforementioned devices. Adobe hasn't reported anything about it in a while, so who knows if this is ever going to get fixed.
I wouldn't recommend using the async upload in production for Android without some sort of detection in place. The good thing is you can still fallback to sync upload if you detect the async upload has failed (i.e. the callback hasn't been triggered for too long).
Thanks for the update, Marcel! I'll ping Adobe again and ask if there has been any progress.
You're right, I could also implement a workaround on Starling's side, as a last resort. I'm considering that!
Hey Marcel, I just received a little more information about this from Adobe. They're saying:
We were not able to reproduce the “texture decoding failed ”issue as Nexus7 devices were not available with us, but we did observe the crash for the sample application attached by the user. We investigated the issue by creating the native application and observed that it is not the AIR runtime issue and was reproducible on the Android 6 devices available with us having Adreno 4xx GPUs.
As I understand this, it seems to be a driver bug Adobe can't do anything about. Which is a bummer, of course. 😞
So I'd like to see if we can add a workaround for this inside Starling. I'd like to avoid a timeout, though, and maybe react to the exception. If you try this on one of the affected devices, could you check where exactly the error occurs?
Thanks in advance, Marcel!
Hi Daniel,
Thanks for keeping an eye on this.
The crash issue mentioned by Adobe was caused by disposing a texture while it was still uploading asynchronously. I think sometimes the error 3677 was thrown instead of a crash and this is what I initially reported (it's been fixed by Adobe). However only later I found the bigger problem is the fact that the event TEXTURE_READY
stops being dispatched by the runtime after some time, effectively keeping the uploaded texture in the "uploading" state forever. When this happens, there is no error thrown or dispatched, basically no feedback at all, which means you will likely need to use a timeout if you want to do something about it. I can't think of anything else to be honest.
We are currently experimenting with a class that handles all the texture uploads in the app and uses a timeout to detect any uploads that take too long. When the timeout is fired, the class fallbacks to using sync upload only. This way the app "recovers" after a small period of time when no new textures appear. We are also using a queue and uploading at most one texture at any given time, so it's fairly straightforward in implementation. As an example, imagine scrolling through a gallery of images:
We haven't used this in production yet, so we don't have any data on how many devices could be affected.
I can reproduce the issue reliably, so I am happy to test any workarounds you might come up with.
Thanks a lot for the additional information, Marcel!
Ah, I see, so the error and the timeout are two separate things. Indeed, that makes it harder to add a workaround. Because when using a timeout, it's difficult to find the sweet spot between "it just takes damn long" and "it's taken too long". :wink: But something needs to be done, otherwise this feature is rather useless on Android.
Perhaps, if you are using this in production, you can report your results here? This would be a huge help!
Yeah it could be tricky to get a workaround in place for this. I will definitely report any production data if we manage to collect any.
However it was just brought to my attention that the async upload has its issues on iOS as well. The textures simply fail to be rendered on the screen after some time and eventually a crash occurs with this stacktrace:
0 libGPUSupportMercury.dylib 0x2be92742 gpus_ReturnUnexpectedKillClient + 2
1 libGPUSupportMercury.dylib 0x2be93202 gpusSubmitDataBuffers + 118
2 libGPUSupportMercury.dylib 0x2be93078 gldCreateContext + 204
3 GLEngine 0x2769ce06 gliCreateContextWithShared + 598
4 OpenGLES 0x27779a8c -[EAGLContext commonInitWithAPI:properties:] + 404
5 OpenGLES 0x277798c6 -[EAGLContext initWithAPI:sharegroup:] + 110
6 Async Upload Sample 0x00029874 0xe000 + 112756
7 Async Upload Sample 0x006d7e40 0xe000 + 7118400
8 Async Upload Sample 0x004b1c48 0xe000 + 4865096
9 Async Upload Sample 0x004b1d70 0xe000 + 4865392
10 Async Upload Sample 0x004b1928 0xe000 + 4864296
11 libsystem_pthread.dylib 0x33bcfddc _pthread_body + 136
12 libsystem_pthread.dylib 0x33bcfd4e _pthread_start + 114
13 libsystem_pthread.dylib 0x33bcdaf8 thread_start + 4
It can be reproduced with the sample project I originally posted at the top, it just takes much longer to occur in this sample (20+ minutes) than what it takes on Android. It looks like the more uploads are made the sooner it happens. There is no issue with sync upload. I can't help but think it is somewhat similar to this Android issue I reported in the past.
I'll try to work up a demo where it is much quicker to reproduce and create a bug report for Adobe.
I created a report for the iOS issue, please leave a vote, thanks!
Awesome — thanks a lot for your efforts, Marcel!
It's an AIR issue but I thought I should let you know about it. I recently found it's possible to crash an app if a texture is disposed while the bitmap data is being uploaded asynchronously; Adobe is currently looking into it.
The actual problem is that the
Event.TEXTURE_READY
event fails to be dispatched after some time on Android, practically leaving the texture in the "uploading" state. Once this occurs, the event is never dispatched for subsequent texture uploads; the app has to be restarted. There is no error and the app continues to run, it's just that any further async texture uploads do not work. Unfortunately, Adobe says they cannot reproduce this, but I think it's pretty serious issue as it eventually breaks the app down.I'm able to reliably reproduce it on devices like Nexus 7 2013 or Sony Xperia Z3, both running Android 6. I haven't encountered this issue on old samsung phone running Android 4. I was wondering if you have ever seen this happen?
In case you'd like to test it on some of your devices, I've created a sample project where a bitmap data is uploaded and disposed repeatedly. If you create
apk-debug
and launch a logcat, you will see a counter that tracks the number of uploads. I've seen the event to stop being dispatched randomly, for example at 90th, 250th or 700th cycle. I'm using AIR 25.0.0.126 and-swf-version=36
.sample-project-upload.zip
EDIT: Added ready-to-use APK of the sample project: com.example.sample.apk.zip