Closed Klug76 closed 8 years ago
Actually, this is a known issue — albeit not documented anywhere. :bowtie:
This only happens when starling.enableErrorChecking
(or the equivalent property on the context) is set to true
. I think this problem was introduced with an AIR / Flash Player update a while ago. Factually, I think it's correct to throw that error, because the ATF texture might really be incomplete at this stage. However, it's almost impossible to recover from a lost context gracefully without being in such a state for a short while. At least I didn't find any way to work around that.
However, any real-life application should always have enableErrorChecking
disabled for performance reasons, so this won't happen on the market. And for testing context-loss situations, the best practice is to simply deactivate it, as well.
Could you try if this is indeed the case? Please also check if this fixes #798 as well, because the new Starling version should handle context loss just as well as previous versions.
Yes that's right. I think it should be put in the FAQ or 2.0 Migration Guide (is there such a document?).
You're right, this definitely needs to be better documented! As a first step, I added that information to the API docs of that method. → http://doc.starling-framework.org/v2.0/starling/core/Starling.html#enableErrorChecking
(That's for 2.0, I'll do 1.x separately.)
A while ago, I integrated this into the 1.8 docs, as well. → http://doc.starling-framework.org/v1.8/starling/core/Starling.html#enableErrorChecking
In the version 1.7 using ATF-textures, any context loss results in the following error:
Stack:
The issue #798 blocks check the version 2.0..