Some sort of memory are not deallocated when Sprite objects are no longer presented.
Attach a Capx
Description of Capx
The capx contains 3 layouts. Layout 1 is blank. Layout 2 and 3 contains 5 and 3 Sprites respectively. All sprites are 2048 x 2048 pixels, and they just contain different solid colors.
You can press 1,2,3 to change to Layout 1,2,3.
Steps to Reproduce Bug
- Step 1 : run Performance Monitor or tools that can monitor memory consumption of processes.
- Step 2 : run capx.
- Step 3 : Change to Layout 2 and then 3 by pressing 2 and 3. You should see memory consumption for the process going up. In this step, you can try go in only one layout and see difference in memory consumption as well.
- Step 4: Press 1 to come back to Layout 1, where there are no sprites at all. In a brief moment, Garbage Collector will release some memory, but you will see that not all memory is released.
Test on Firefox:
On Firefox, going to layout 2 with those big Sprites and back, the memory consumption comes back only half way. It never goes down ever.
Test on Chrome:
On Chrome, we see similar development just like Firefox.
However, you can force garbage collector to do its job by minimizing Chrome, and this is what we get:
Usually for Chrome and Node Webkit, there are 3 processes, so each line above goes to each process. The green line is the main process, we believe. When we change layouts around, it goes up. When we do nothing, it goes down. When we minimize Chrome, it goes way to the bottom. However, what is interesting is the blue line. We noticed that whenever we allocated more texture memory (ie. sprites are presented when we switch to another layout), the blue line rises up. However, it never comes back down.
We have also checked against different number of Sprite in capx. We tried only one Sprite instead of five, and switching to this layout only. We got the following result:
Note that the blue lines in figure 4 and 5 are the main process (basically green line in Figure 3) and the red line is actually the same process as blue line in Figure 3. (we accidentally close Performance Monitor and we didn't change color back when we start over)
This is to demonstrate that the blue line in Figure 3 correlates with texture memory.
We also recalled from the section "A word on texture loading" in https://www.scirra.com/blog/112/remembe ... our-memory :
[quote:38engof9]When the layout ends, it will free all the images in memory not used by the next layout, and load any new images the next layout uses.
So we decided to checked against our GPU whether texture is deallocated or not.
Here are our results:
Exported Node Webkit:
Preview Firefox: (NOTE: the reason that you see it going down here is because that was leftover from our other experiment. Firefox process begins when it rises up again at half way on the graph)
Preview Node Webkit:
We see memory juggling in Preview Chrome and Exported Node Webkit as we switched between the 3 layouts. It always get back down when there are no Sprites. On the other hands, we see memory going up but never come down in the other two.
Perhaps we could say : Preview Chrome and Exported Node Webkit have texture deallocated when Sprites are no longer presented. Preview Firefox and Preview Node Webkit do not have texture deallocated.
This is ok for us, as our focus is Chrome and exported Node Webkit. Nevertheless, recall the blue line from Figure 3, could you please check whether anything can be done?
No longer required memory should be released.
- Chrome: YES
- FireFox: YES
- Node Webkit: YES
Operating System and Service Pack
Win 7 64 bits Service Pack 1
Construct 2 Version ID