PsychoJS platform version 2020.1 - Memory Leak in Visual Stimulus Setters

There is a memory leak in PsychoJS platform version 2020.1 caused by the stimulus setters and the subsequent call to the _updateIfNeeded() not releasing the resources of the attached _pixi object. I confirmed and fixed this issue for both TextStim and ImageStim but the same issue is very likely also present for other visual components (I did not check this).

I created two public demo experiments containing only a text stimulus that updates its text content every frame (the actual content stays the same but the update calls the setText function in turn triggering the _updateIfNeeded function). This is to demonstrate that this memory leak is particularily problematic when using “set every frame”.

URL of experiment using the current PsychoJS platform version 2020.1:

URL of experiment with my bugfix applied to the current PsychoJS platform version 2020.1:

This is how to fix the bug in PsychoJS platform version 2020.1:

The PIXI objects created by the PsychoJS visual library need to be released before the creation of a new object. This can be done by calling the .destroy(true) function on respective objects within the _updateIfNeeded() function.

For TextStim.js, for example, I add the following code

if (typeof this._pixi !== 'undefined')

just before the creation of the new PIXI stimulus
this._pixi = new PIXI.Text(this._text, { ... and so on

The same is true for ImageStim (see also the html/lib_bugfix/visual-2020.1.js within the second project linked above).


Thanks so much! I was wondering what was causing these crashes in my typing experiments. Glad someone with more skill was able to solve the issue.

This should be included in the next update.

1 Like

Hi Frank, well done to chase this down.

Have you reported it as an issue (along with the suggested fix) at the PsychoJS Github repository? It make it much more likely to get actioned compared to posting here, where things can easily get lost or not come to the right person’s attention.

Hi Michael,

good point! Following your suggestion, I just opened an issue at Github:


Thanks Frank. The cause/fix matches what I expected but great that you tracked down a particular fix. We’ll make sure this is fixed in the 2020.2 series.


Hey Frank,

Thanks a lot for providing this fix! I’ve updated my experiment with your bug_fix lib and updated the import statements in my experiment’s main .js file; this has minimized crashing/freezing resulting from this memory leak for most participants. That said, correct me if I’m wrong, but the fix doesn’t seem to apply to the .js file used for older browsers. Do you happen to know of an alternative solution for older browsers? Memory leakage via text components is the main issue in my experiment for participants with older operating systems and browsers.

Thanks a lot,

Hi Ilana,

yes, this is correct. This should fix the issue for recent browsers only. For our experiment, this was sufficient because we only allow users using either Firefox or Chrome to participate and basically all of our participants use recent enough versions of both browsers.

Thus, I did not look into the legacy version. However, according to Jon (see Github thread), version 2020.2 is around the corner and will include a fix. Thus, my best solution would be to allow only recent browsers for now until 2020.2 is released.

All the best,


Ok, good to know. On the edge of my seat for 2020.2! Thanks for your help thus far, and best of luck with your own experiments.


1 Like

Thank you so much! This worked wonders. We were experiencing an issue where after 40 minutes of a basic task involving a simple recall and response (the user had to type and we would update the text every frame), memory usage went from 170 KB up to 1.5 GB.

Using Frank’s lib_bugfix, I’ve created a Python script that automates the update process, so all you have to do is place this in the root of your experiment (the folder containing the html/ folder) and then run it after each HTML export and before you sync. Note that on Windows, if your environment PATH isn’t setup right, you may have to run the script from a command prompt instead of just double clicking. (179.8 KB)

Also, here’s the results:
Memory_Footprint Leak_Rate