RenderTexture can crash if games are created and destroyed in quick succession.

[timiyay]

This Issue is about

• A bug in the API:
  • Phaser version(s): 2.19.2
  • Live example: https://codepen.io/timiyay/pen/NWMaRKj
  • What steps produce the bug:

function newGame() {
  return new Phaser.Game({
    state: {
      create() {
        this.game.make.renderTexture()
      }
    }
  })
}

let game = newGame()
game.destroy()
game = newGame()

• What should happen: the 2nd instantiation of the game should not crash, and should be able to create a RenderTexture
• What happens instead: the code crashes
• If there's an error:
  • What's the error message? Uncaught TypeError: Cannot read properties of null (reading 'type')
  • What's the error trace (expand the error message)?
    

Crash occurs at https://github.com/photonstorm/phaser-ce/blob/1af938320a72ebc0cfbd9cc9101fcf1bf17d9808/src/gameobjects/RenderTexture.js#L86

Background

We're using a NextJS/React client to run some Phaser games. We're using React's effects inside functional components, since the rendering of a Phaser game is considered a side effect outside of React's control. In development, React has a Strict Mode that will cause these effects to double-render these functional components, in order to help devs identify unintentional side effects in their code

This means our Phaser games are being created, very quickly destroyed, then created again. Some of our games use RenderTexture, which isn't resilient to these quick create/destroy/create cycles.

The issue appears to stem from RenderTexture's reliance on global state; specifically, PIXI.defaultRenderer.

https://github.com/photonstorm/phaser-ce/blob/1af938320a72ebc0cfbd9cc9101fcf1bf17d9808/src/core/Game.js#L1279

I think what's happening is Phaser.Game#destroy will set PIXI.defaultRenderer to null, which causes a race condition where the 2nd game's renderer may or may not be null.

I am happy to contribute a PR, once folks have a chance to triage and comment on the issue.

[samme]

I think I have a branch for this.

[samme]

Fixed in dde4ef2

[timiyay]

Thanks! 🙇

[timiyay]

Hi @samme thanks again for the fix for this issue.

Do you have any plans to release it in the near future? It's still affecting us so we may need to consider a fork, or depending directly on this Github repo, in the meantime.

[samme]

I'll make a release soon.

[timiyay]

Thanks @samme 🙇