An Investigation into Memory Leaks

August 1, 2020

There are some things to keep in mind while reading this chart. My computer normally hangs around 50% committed bytes in use while no programs are running, and it’s a decent enough laptop with an Intel core i5 (8th gen) and a NVIDIA Geforce… thing (I’m not really a computer expert, I just read the stickers on it). I also don’t have an Apple computer to test on Safari, so I don’t know what would happen there.

Additionally, both of the versions of these games that were tested are the versions currently published to Newgrounds as of this post’s date, including Astronaught on Itch.io. Astronaught had been recently updated to use as little drawing code as possible, and the only times text is drawn is during the “Made by Imminent Death” intro, the “Press any button to play” text on the title screen, and whenever hints are displayed at the top of the screen. Both the “Paused” and “Game Over” displays are actors, and hints also don’t draw if you pause the game while they’re displayed, so that they can’t be left to build up memory (I also noticed that certain transitions between scenes was messing with memory, but since this isn’t drawing code I wasn’t sure why, so I just changed the transitions). I haven’t made an update for Darkhouse, because there is text in that game that I just can’t remove because the game was designed that way.

Results and Conclusion

With that in mind, what this chart shows is that Firefox is the only browser that doesn’t get rid of it’s memory. Google Chrome, Internet Explorer, and Microsoft Edge are all able to hang around generally the same amount of memory usage, with some variation depending on which of them was used. But in Firefox, memory builds up and is never released. In Astronaught, an additional 4% of memory built up after 2 minutes, and in Darkhouse, about 20% more memory was added. The memory never went down, either, only up at a rate that seems to depend on how much drawing code is running at the time. Something I had noticed specifically while I was monitoring Darkhouse was that the memory went up a lot faster on the title screen where a lot of text is drawn, and then slowed down once the game started. It picked back up again when I got to the room that displays “Defeat 10 Enemies” text, confirming that drawing text causes the memory leaks.

I’m not sure if anyone else has been experiencing memory leaks like this in other browsers. I know I’ve had bugs show up before in entirely different scenarios, and the patches I’ve released seem to have fixed them. But while my findings have shown that Firefox seems to be the only problem, it’s possible that I missed something somewhere. So if you decide to do this experiment yourself, I’d love to see your results. I like science, and science is all about figuring things out, so any additional information on this would be greatly beneficial.

Now I have absolutely no idea how to fix this memory leak problem, so it presents a huge conundrum for how I’m going to develop and release future games. Astronaught was an easy game to fix (sort of) because it doesn’t have any mechanics directly tied to drawing text. I could go and replace every single-word or double-word text with actors that have animations, and I could make an actor for the oxygen bar as well (though it inconveniently needed a hundred individual frames in order to work correctly). But the reason why I haven’t tried to fix Darkhouse is because it has score, and there’s no way I can design a UI element like an actor to display it other than with text. I’d have to have a frame for each possible score you could have at any given moment, and there’s technically no limit to the amount of score you could get in Darkhouse. The same goes for drawing dialogue, something that will be very important for “that one game that I’m making.” There’s just no way I can show all the different variations of words and numbers without using text.

So if Firefox really is the only browser that can’t keep up with the memory usage, and it looks like it won’t be fixed for a while, then I’m just going to say that you shouldn’t play any of my games in Firefox. I’m not going to stop and wait for a fix, or avoid drawing code forever and try to come up with arduous workarounds that just aren’t worth the time and effort it would take. It’s not like I’ll be filling my games with text left and right, either, I’ll try and ignore drawing whenever I can. But when it comes to games with dialogue, score, or other potentially large numbers, there are at least three other browsers that I have scientifically deduced are safe to play in (I guess that means my hypothesis was correct, at least until proven otherwise). I’ll start putting warnings at the start of every game I make as well, like “This game has potential memory leaks in Firefox, please play it in a different browser,” or something like that. I’ll also be making a bug report on Stencyl’s forums to report my findings directly to them, in hopes that this information might help towards fixing this issue.

To summarize (since I know my blog posts can be pretty lengthy), it looks like Firefox is prone to memory leaks in HTML5 games that were made in Stencyl (and possibly other engines). The memory is never released, and increases at a faster rate when more drawing code is running, such as with text and boxes. It also seems that Firefox is the only browser that does this, with Chrome, Internet Explorer and Microsoft Edge controlling memory just fine. Still, I will be making games that will most likely have drawing code in them, though I’ll use it sparingly, and I’ll add a warning at the start of each game to not play it in Firefox.

I hope you all can understand and agree with this decision, because you like playing games and I like making games, but I’m still trying to figure out how to make games. I have a lot of ideas that I want to develop that I think will be really fun, and I’m not going to let one stinky browser inhibit me from doing that. Hopefully it does get fixed sometime in the future, but for now I think a warning to switch to a working browser is a fair enough compromise.