Adobe-Runtime-Support
Adobe-Runtime-Support copied to clipboard
Asynchronous Texture Upload Failure with Linux Runtime
First of all, congratulations on all your work with the Linux runtime!
We are over-the-moon excited about it! Thank you.
Problem Description
Asynchronous texture uploads fail when using the Linux runtime. There is no issue uploading asynchronously when using the Windows or Android version of the runtime. Synchronous uploads do work with linux.
AIR SDK: 33.1.1.743
Steps to Reproduce
Below is a simple example. It can be done with any embedded image. There are no dependencies out side a simple logger class which would be replaced with trace statements. I've eliminated all the code related to actually displaying the texture so as to simply the example. I can provide that if desired.
package com.xpodigital.video { import flash.display.Bitmap; import flash.display.BitmapData; import flash.display.Sprite; import flash.display3D.Context3D; import flash.display3D.Context3DTextureFormat; import flash.display3D.textures.Texture; import flash.events.ErrorEvent; import flash.events.Event;
[SWF(backgroundColor="#FFFFFF", frameRate="31", width="640", height="480")]
public class ImageUploadTest extends Sprite {
private var W : int = 640;
private var H : int = 480;
private var context : Context3D;
private var texture : Texture;
private var logger:PipeLogger;
[Embed(source="lobby1.jpg")]
private static var lobbyImage : Class;
public function ImageUploadTest() {
// This is a simple logger which writes to a pipe file. logger.localLog can be substituted with trace statements.
logger = new PipeLogger();
logger.localLog("Texure test instantiated!");
if (stage) {
init();
} else {
addEventListener(Event.ADDED_TO_STAGE, init);
}
}
private function init(event : Event = null) : void {
removeEventListener(Event.ADDED_TO_STAGE, init);
logger.localLog("Init called");
if (hasEventListener(Event.ADDED_TO_STAGE))
removeEventListener(Event.ADDED_TO_STAGE, init);
// requesting a Context3D instance using the Stage3D API
stage.stage3Ds[0].addEventListener(Event.CONTEXT3D_CREATE, initMoleHill);
stage.stage3Ds[0].requestContext3D();
}
private function initMoleHill(event : Event) : void {
logger.localLog("3D Context Created");
context = stage.stage3Ds[0].context3D;
context.enableErrorChecking = true;
context.configureBackBuffer(W, H, 4, true);
var data:BitmapData = Bitmap(new lobbyImage()).bitmapData;
logger.localLog("bit map data instantiated");
texture = context.createTexture(data.width, data.height, Context3DTextureFormat.BGRA, false);
// Synchronous upload -- THIS WORKS!
/*
texture.uploadFromBitmapData(data);
logger.localLog("Texture uploaded synchronously");
Call render logic here
*/
// Asynchronous upload - THIS DOES NOT WORK
texture.addEventListener(Event.TEXTURE_READY, onAsyncTextureReady);
texture.addEventListener(ErrorEvent.ERROR, onAsyncTextureReadyFail);
texture.uploadFromBitmapDataAsync(data);
logger.localLog("Texture async upload called");
}
private function onAsyncTextureReady(event:Event):void
{
event.target.removeEventListener(Event.TEXTURE_READY, onAsyncTextureReady);
event.target.removeEventListener(ErrorEvent.ERROR, onAsyncTextureReadyFail);
logger.localLog("async texture upload succeeded!");
// Call render logic here
}
private function onAsyncTextureReadyFail(event:Event):void
{
event.target.removeEventListener(Event.TEXTURE_READY, onAsyncTextureReady);
event.target.removeEventListener(ErrorEvent.ERROR, onAsyncTextureReadyFail);
logger.localLog("async texture upload failed!");
}
}
}
Known Workarounds
Use synchronous uploads. Unfortunately to get the frame rates required for our application, this is an undesired approach (as images will be dynamically loaded throughout runtime and not just during startup.)
Issue still exists with latest AIR 51.2.1.4. Tested with multiple Linux devices, with multiple applications (Stage3D/Straling). Also maybe related issues: https://github.com/airsdk/Adobe-Runtime-Support/issues/32 https://github.com/Gamua/Starling-Framework/issues/947
Hi @xpojosh - we had looked into this one but it seems hadn't posted our findings here.. the issue with this feature on Linux was due to some of the OpenGL acceleration code which was not able to set up the shared GL contexts required for being able to then upload a texture via a different thread. Our aim was to support this feature via the move over to OpenGL ES which is a more robust/complete implementation as it's the code already running on the mobile devices.
We can have another quick check perhaps, having done some updates around here for the VideoTexture handling, but then I'll also ask someone to confirm this case works as we switch to OpenGL ES + ANGLE.
thanks