Starling.updateViewPort raises error when context got disposed

[tk-1io]

Setting mStarling.viewPort when the stage resizes (by rotating the device) raises an error on Android:

Error: Error #3694: The object was disposed by an earlier call of dispose() on it.
at flash.display3D::Context3D/configureBackBuffer()
at starling.core::Starling/updateViewPort()[/Users/redge/Development/starling/starling/src/starling/core/Starling.as:257]
at starling.core::Starling/set viewPort()[/Users/redge/Development/starling/starling/src/starling/core/Starling.as:537]
at Test/onResize()[.../ViewPortBug/src/Test.as:27]
at starling.events::EventDispatcher/dispatchEvent()[/Users/redge/Development/starling/starling/src/starling/events/EventDispatcher.as:109]
at starling.display::DisplayObject/dispatchEvent()[/Users/redge/Development/starling/starling/src/starling/display/DisplayObject.as:328]
at starling.core::Starling/onResize()[/Users/redge/Development/starling/starling/src/starling/core/Starling.as:398]

[PrimaryFeather]

Have you set "starling.handleLostContext" to true? This is required on Android!

[fljot]

Also doesn't work for me, even though handleLostContext is set to true.

[joshtynjala]

I've seen this on Android and Windows with handleLostContext set to true. If I change the Starling viewPort when the native stage resizes, it throws this error. It seems to recover well enough if I wrap the call in a try-catch.

[jamikado]

This is interesting because my current Starling app is ported and running on Mac, Windows, iOS and Android.

I also have handleLostContext = true for Android and Windows and the app also supports autoOrient and I am definitely loosing contexts and recovering on device rotation in Android but I have never had this exception occur (or maybe I am not aware of it occurring and the app is recovering without incident)

One potential difference is that I am causing my Starling updateViewPort with a handler that is attached in my startup class and on the flash stage flash.events.Event.RESIZE and not the Starling Event.RESIZE.
I am also adding my event handler in my startup class before I even instantiate Starling.

Is it possible this issue could be sensitive to whether user code is reacting to resizes or lost contexts before or after Starling is reacting to these events?

[joshtynjala]

I listen on the native stage, with the highest priority possible to ensure that Starling's stage.stageWidth/Height reports the correct values when my components react to the Starling's stage resize event (ScreenNavigator, for instance, defaults to stage dimensions, if width and height aren't set explicitly).

this.stage.addEventListener(flash.events.Event.RESIZE, stage_resizeHandler, false, int.MAX_VALUE);

It all ends up being pretty messy with this and the try-catch and all that. It would be better if Starling could resize its own stage (or provide an option, even if it's not default) because I can't guarantee that Foxhole users will handle resizes the same way, even if that's how my example code does it.

[tk-1io]

Yes, starling.handleLostContext is set to true... maybe a

mContext.driverInfo != "Disposed"

in the updateViewPort() method could help, like in the render() method

EDIT: wow, you commited that solution at the same time i posted this ;-)

[PrimaryFeather]

Thanks for the infos, guys! I'm now checking if the context is still valid when the method is called.
Josh, I'll think about adding an option that automatically updates the stage size; providing an option to do so might be useful.

[PrimaryFeather]

Hehe, tk-1io, it seems we had the same thought at exactly the same time! ;-)