I am using phaser to create a gameobject on the fly for some simple animations sequences. I destroy the game object when the animations are completed and go back to the regular page layout until a game/animation is triggered again. It seems the Chrome renderer memory usage goes up with every play until chrome finally crashes. The page is displayed in incognito with no caching so everything is loaded for each play as it is needed.
Does anyone see a problem with this approach? Should game.destroy be taking care of clearing everything from the previous play? Is there any issues with using the game object in a global scope as long as destroy is being used properly?
Based on some digging it looks like game.destroy may of not been fully implemented on the version I was using (3.11) but I switched to 3.16.2 and it still persists.
So the animation plays and stays the screen for 30 seconds once finished animating, (timer controlled by a C++ application using communication over websockets). This timer could be interrupted by a request to play another animation. If that is the case I must clear what is currently on the screen and start the next animation.
If the timer times out it will call a function to resume normal activities which will check if an animation is currently on the screen (by looking at the game object) and remove it:
if (typeof game != "undefined")
game.destroy(true);
But when another animation is started it needs to check if one is currently on the screen and if it is ,remove it and start a new one. (It could be one of two different animation/games). Because I suspect this is likely the way I am structuring the javascript and not a particular phaser issue, here is the stripped down animation structure to start.
play_animation() is in its own .js file and game is defined in a global space in main.js
function play_animation(anim_data)
{
// Destroy animation if there is one on the screen already before starting next
if (typeof game != "undefined")
game.destroy(true);
initialize:
function starting_scene() {
sprite_arr = [];
Phaser.Scene.call(this, { key: 'starting_scene' });
},
preload: function () {
},
create: function () {
}
});
var exit_scene = new Phaser.Class({
Extends: Phaser.Scene,
initialize:
function exit_scene() {
total_winnings = null;
outcome_sprite_key = null;
Phaser.Scene.call(this, { key: 'exit_scene' });
},
preload: function () {
},
create: function () {
}
});
var config = {
type: Phaser.AUTO,
enableDebug: false,
width: 1920,
height: 1080,
scene: [starting_scene, exit_scene],
parent: "full_screen",
};
game = new Phaser.Game(config);
}
Well, a little better, but it’s still ambiguous O_o
For me, the question is why you eliminate the whole game and rebuild it!
shutting down the scene and start it again makes it a problem for you?
Thanks for the info samme… I tried running the profiler and if I am understanding it correctly I think something might not be getting cleaned up. I see x7 for WebGLContext which corresponds with how many times I let the interval loop.
Maybe I am missing something or structuring this code incorrect but I would expect game.destroy to be taking care a lot of the low level game data cleanup.
I am running this small sample to simulate below:
$(document).ready(function () {
play_game();
setInterval(play_game,10000);
});
function play_game()
{
var main_scene = new Phaser.Class({
Extends: Phaser.Scene,
initialize:
function main_scene() {
Phaser.Scene.call(this, { key: 'main_scene' });
},
preload: function () {
console.log("START");
// IMAGES
this.load.multiatlas('images', 'SVN.url.json');
this.load.on('complete', function () {
console.log("DONE LOADING");
});
},
create: function () {
game.destroy();
console.log("DESTROYED");
}
});
var config = {
type: Phaser.AUTO,
enableDebug: false,
width: 1920,
height: 1080,
scene: [main_scene],
parent: "full_screen_div"
};
var game = new Phaser.Game(config);
It seems like this example may have the same issue, in my my case I am just using more assets so I run out of memory before reaching 15 contexts. But it the memory keeps growing until about 15 destroys then the oldest webgl context starts getting dropped.
