00:00
00:00
ImmanentDeath
Keeper of the Lunar Lighthouse.

Joined on 12/29/17

Level:
11
Exp Points:
1,327 / 1,350
Exp Rank:
48,869
Vote Power:
5.36 votes
Rank:
Civilian
Global Rank:
> 100,000
Blams:
0
Saves:
23
B/P Bonus:
0%
Whistle:
Normal
Trophies:
1
Medals:
239
Supporter:
1y 9m 22d

An Investigation into Memory Leaks

Posted by ImmanentDeath - August 1st, 2020


iu_150770_6694842.png


Over the past few months, I’ve been struggling with an infamous problem in my games, more prominently in Astronaught, that I hadn’t originally noticed while testing but that many people have brought to my attention. They reported that the game had memory leaks that were causing their browsers to freeze and crash, and so I set out to try and figure out what was causing this. What I discovered was that these leaks are a complicated and frustrating issue that seems to be irritating a lot of other people as well, and try as I might, I just couldn’t solve it. So I decided to compile all of my research into this blog post, and conduct a little experiment to see what exactly was going on in my own games (I didn’t really follow the scientific method intentionally, but I guess the question I asked would be “Why are my games leaking memory when I draw things?”).


Research and Past Experiences


First of all, these memory leaks only seem to occur in HTML5. When I released my first game Darkhouse, I never encountered anything like this, and I think it’s because Darkhouse was originally a Flash game. I had later changed it to be an HTML5 game when browsers started to disable Flash by default, and it seemed neither I nor anyone else noticed any memory leaks afterwards (at least until I did my experiment). But when I released my second game Astronaught in HTML5, a lot of people reported lag.


Second, the memory leaks are greatly worsened by drawing text and boxes on the screen. A while ago I found this thread on the Stencyl forums which reported that HTML5 games leak memory while drawing, and this other thread states that not only are a lot of people having this issue, but that the issue is caused simply by using drawing code, because it costs memory to update the screen and sometimes that memory can build up. The best option to alleviate this was to just not draw anything on the screen, ever. It had taken me a long time to figure out that this was what was happening in my games.


Lastly, it looks like memory leaks are only happening in Firefox. My browser of choice is Google Chrome, and that’s what I’ve been using to test my games because it runs well and I haven’t encountered many problems with it. So I was a little confused when people started reporting lag problems that I had never seen before, and I thought maybe it was a problem with different browsers. There were a lot of people that didn’t seem to have issues at all, and most of the people that did said that they were using Firefox, though a few of them said they use Chrome, and some of the Stencyl forum posts have also reported that they experienced leaks in Chrome. I had already encountered some other bugs before in Chrome, but I had released patches that seem to have fixed them. So while it looked like it was mostly Firefox that leaks memory, I wasn’t sure.


The Experiment


So I decided to design an experiment to see what exactly was happening in my games using different browsers (my hypothesis would probably be that Firefox is the most susceptible to memory leaks, because I had suspected this while I was researching and testing). I pulled up my Performance Monitor app on my computer and played both Astronaught and Darkhouse for about 2 minutes in four different browsers, taking screenshots of the memory both before and after playing. I took every “after starting” screenshot once the game was fully loaded and it displayed it’s title screen, and then set a stopwatch and played for about 2 minutes, after which I took the next screenshot. Then I composed this chart to display my results:


iu_150771_6694842.png

(open the image here for a better resolution)


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.


iu_150772_6694842.png


1

Comments

Comments ain't a thing here.