If a desktop AIR app is minimized, it may render with a blank white screen when the window is restored later. Moving the mouse around may cause Starling to start rendering again if the interaction triggers anything that might require a redraw.
There are a few requirements to reproduce this issue:
1) Windows only. The issue does not reproduce on macOS.
2) Must be using Context3DProfile.BASELINE_CONSTRAINED.
3) skipUnchangedFrames must be true.
4) Must NOT stop Starling on Event.DEACTIVATE and restart it on Event.ACTIVATE.
To fix this issue, I added a listener for Event.ACTIVATE inside the Starling class. In the listener, I call setRequiresRedraw() after a 100 ms delay. Calling it immediately did not work for me. This is the same workaround that already exists in start() (the comment says it may be required on Android), but it works even if you want to allow a desktop app to render while in the background.
I did not remove the existing workaround in start(), but I think it may be redundant now.
If a desktop AIR app is minimized, it may render with a blank white screen when the window is restored later. Moving the mouse around may cause Starling to start rendering again if the interaction triggers anything that might require a redraw.
There are a few requirements to reproduce this issue:
1) Windows only. The issue does not reproduce on macOS.
2) Must be using Context3DProfile.BASELINE_CONSTRAINED.
3) skipUnchangedFrames must be true.
4) Must NOT stop Starling on Event.DEACTIVATE and restart it on Event.ACTIVATE.
To fix this issue, I added a listener for Event.ACTIVATE inside the Starling class. In the listener, I call setRequiresRedraw() after a 100 ms delay. Calling it immediately did not work for me. This is the same workaround that already exists in start() (the comment says it may be required on Android), but it works even if you want to allow a desktop app to render while in the background.
I did not remove the existing workaround in start(), but I think it may be redundant now.