I expected this to be an issue given the recent release to bring ByteArray towards the Flash implementation, makes sense not to have 2 classes that do about the same thing. It looked as though this had been solved in a previous pos from a few weeks ago on OpenFL 3.5.3 :
but the class does not exist for me in lime\2,9,0\lime\utils. This was the case when I was on OpenFL 3.5.3 also, and is still the cse now that I have upgraded to 3.6.0.
It doesn’t look like the OpenFL ByteArray is fully compatible, but I’ll try to keep track of the issues that I come across in the conversion over here.
I have managed to get what I want using this function (which unfortunately highly coupled with HTML5), so I will not be touching BytesArray for the next little bit most likely.
public static function encodeBase64(image:Image):String
{
if (image.premultiplied || image.format != RGBA32) {
// TODO: Handle encode from different formats
image = image.clone();
image.premultiplied = false;
image.format = RGBA32;
}
ImageCanvasUtil.sync(image, false);
var data:String = image.buffer.__srcCanvas.toDataURL ("image/png");
return data;
}
Unfortunately the test failed on the HTML5 target. The PNG.encode is returning Null when given a BitmapData.image. Maybe I am hitting some size limit? I can confirm that in the same environment, the direct approach is continuing to function.
Through that section I linked, try and see if it errors out (if each line traces) and if you get the string data like you do with your own code (before it converts to bytes)
By the way, in the “package lime.graphics;” “Image.hx” class, the contents “private function __fromBase64()”, are conditioned to execute only under JS and HTML5.