Texture is not fully uploaded visually when async callback is called

[joshtynjala]

Hey, Daniel! I suspect that this is probably an AIR issue, but I thought I'd run it by you to see what you think.

When uploading a very large (3840x2880) BitmapData asynchronously to an existing texture, I can actually see it changing from the old texture to the new one after the async callback has been called.

var texture:Texture = Texture.fromEmbeddedAsset(TEXTURE1, false, false, 12);

var image:Image = new Image(texture);
image.y = 30;
this.addChild(image);

var flag:Boolean = false;
function asyncCallback():void
{
    if(flag)
    {
        button.alpha = 1;
    }
    else
    {
        button.alpha = 0.25;
    }
    flag = !flag;
}
var button:Button = new Button(Texture.fromColor(150, 20, 0xcccccc));
button.text = "Change Async Texture";
button.addEventListener(Event.TRIGGERED, function():void
{
    if(flag)
    {
        texture.root.uploadBitmap(new TEXTURE1, asyncCallback);
    }
    else
    {
        texture.root.uploadBitmap(new TEXTURE2, asyncCallback);
    }
});
this.addChild(button);

TEXTURE1 and TEXTURE2 are embedded bitmaps. I have attached two sample files.

https://cloud.githubusercontent.com/assets/141885/22160812/2a79c7c6-defc-11e6-8090-4b313cc1062e.jpg https://cloud.githubusercontent.com/assets/141885/22160813/2a7cace8-defc-11e6-9353-17c02d930c0f.jpg

Notice that asyncCallback contains code that changes the alpha property of the button. You can see that happen almost immediately, but you can actually see the new texture load from top to bottom after that.

Tested on an iPod Touch 5th gen and iPad Mini. A quick test on a higher end Android phone that I had handy didn't have the progressive loading, but I think I could see the texture change all at once a moment after the button alpha changes. I wish I had a lower-end Android that supported textures larger than 2048x2048 to compare.

I'm trying to support async textures in the Feathers ImageLoader component. When reusing the texture, I had hoped to set visible to false before the upload so that the old texture wouldn't be rendered. Then, I'd set visible back to true in the async callback. However, since the async callback seems to be happening too early, I'm not sure what to do.

[PrimaryFeather]

Hi Josh! I just tried it on a rather fast Android device (recording the display in slow motion with the iPhone), and here it worked correctly: I first saw the texture change from top to bottom, and the button changed its alpha exactly at the end of that process.

In my office, I've got some older test devices that will make it easier to check. I'll try it out on Monday and will get back to you!

Thanks for the report, in any case! I agree, though, that it's probably an AIR issue. Still, the more information we can collect about the problem, the easier it will be for Adobe to provide a fix.

[PrimaryFeather]

Okay, I just tried it again on a Nexus 7 (1st gen) and an iPhone 4. (Had to size the texture down to 2048x2048 first.)

The first time I click the button, the callback seems to be correct — the texture changes, then the alpha value. In all subsequent calls, the callback is executed too soon.

I had another thorough look at my own code, and I can't see that I'd be doing anything wrong. In my opinion (too), this must be an error on the side of Stage3D. Should I create a bug report, or do you?

[joshtynjala]

Thanks for looking into it, Daniel! You probably have a better understanding of how Starling interacts with Stage 3D at that level, so maybe you should create the bug report.

[PrimaryFeather]

I created a pure Stage3D test project for the bug report, and it showed the same problem — so it's definitely a Stage3D issue. Furthermore, it only happens with RectangleTexture objects, not regular (POT) Texture objects.

Here is the bug report: Adobe Tracker: TEXTURE_READY event dispatched too soon when uploading to RectangleTexture repeatedly

BTW, I could also reproduce it with high-end devices now.

[PrimaryFeather]

Since Starling can't do anything about it, I'll close this issue now. In the meantime, to anyone reading this: votes for the bug report above are appreciated! :smile:

[PrimaryFeather]

For reference, Adobe fixed this really quickly, and the problem hasn't been observed since. A quick test with AIR 31 I just made had everything working perfectly fine.