Resizing a Starling app causes a crash

[TerryCavanagh]

Hey again! I've been trying to figure out why I can't get resizing to work with my Starling app, and I think it might be due to a bug in haxe Starling. Using the current v1.8 branch, trying to resize a window with any textures in it causes a crash.

Here's a simple example project:

resizebug.zip

This program

• Loads in the starling bird texture and adds it to the stage
• When you attempt to resize the stage, you get the following error:

[Fault] exception, information=Error: Texture type not supported: flash.display3D.textures.Texture

in starling.textures.ConcreteTexture.hx, function createBase(), line 251.

(I currently can't build on any target other than flash (https://github.com/openfl/starling/issues/25), so I don't know if this only affects flash, or if affects all targets.)

[TerryCavanagh]

(here's the source code from the zip above:)

package;

import starling.core.*;
import starling.display.*;
import starling.textures.*;
import starling.events.*;
import openfl.Assets;

class Game extends Sprite {
    public function new() {
        super();    
        addEventListener(Event.ADDED_TO_STAGE, onAdded);
    }

    public function onAdded(e:Event) {
        var tempimg:Image = new Image(Texture.fromBitmapData(Assets.getBitmapData("assets/starlingbird.png"), false));
        addChild(tempimg);
    }
}

Also of note, the exception is thrown before any ResizeEvents are captured

[jgranick]

Does anyone have an environment where they can test the ActionScript version of Starling 1.8, and see if it has the same behavior? I'm not set up to compile ActionScript

Thanks :smile:

[TerryCavanagh]

Ok, just checked! I'm attaching an AS3 starling 1.8 project that does the same thing as the haxe example. It doesn't have the crash on resize!

starling as3 test.zip

(really happy you're looking into this!)

[vroad]

Looks like context gets lost when you resize FlashPlayer window. (I saw the stack trace with debug version of FlashPlayer).

With higher Context3DProfile (such as baselineExtended) context doesn't get lost, but https://github.com/openfl/starling/issues/31 prevented Starling from using best available profile. You should be able to avoid this issue by passing "auto" (or any profile you want) to profile parameter.

I'm not sure why Starling fails to restore lost texture though. Std.is failed to work on flash somehow? Then why Type.getClassName worked?

Should we use getQualifiedClassName instead, like original AS3 version?

https://github.com/openfl/starling/blob/323d073bc2d354f5e032b7881390d4c3604da0f7/starling/textures/ConcreteTexture.hx#L237-L253

[jgranick]

Thanks guys, it seems to work now! :smile:

[TerryCavanagh]

Ahh, nice! Thank you :D