matrixreal

This is Closed Bug Report forums. Please post your question at Beginner's Questions forums instead:

Ashley

[quote:mfboy7a1]Do you think it would be useful for us to add a feature to unload sounds still?

For me, anything allocatable should also be deallcatable. For my project in the end, there could be 600-700 MB of sound when all sounds are in the memory. Sure, we have like computers with 8 GB these days, which makes 600-700 MB not much of a concern. But for lower end devices with only 1 GB of RAM or less, unloading might allow bigger games another possibility to optimize for more memory if required. I recall Wii U got 2 GB of RAM; 1GB of RAM is allocated to system functions and only 1 GB is available for the game. Correct me if I am wrong, but is this 1 GB also used for storing texture memory as well?

So for bigger games with a wide range of variety in sound effects, unloading audio is definitely necessary for devices with limited memory.

C-7

[quote:mfboy7a1]to my knowledge, only one Music track can be played at a time

I just tried a new capx and stream 8 music at once via Preview Chrome. All music seem to play fine simultaneously.

[quote:mfboy7a1]For most users, this is sufficient, but I currently preload necessary music parts when entering a new section of my game and the soundtrack changes dynamically based on player location, game state, and other input.

Similar to Sid Meier's Pirates! (2004)'s town scenes, I suppose? I did have tried something like that too. Streaming in C2 is designed to stream from the beginning first. Jumping around in the audio would cause a long pause. So in that case, I loaded musics as sound effects just like you.

Hey, Ashley, I just downloaded and tried r177.

Preload sounds YES on game startup:

Preload sounds NO on game startup:

All right. I see all 132 sounds (only 6.71 MB OGG in total) taking only 240 MB. Fair enough, I apologized for the trouble. Thank you for your assistance as always.

And my game only saves on the start of the layout though. When I disabled that save game action, it does not show such error on Firefox.

Ashley, I just hit preview from Construct 2 to preview on Firefox and I got that error. There were no other steps.

Ashley, I used those music as sound effects to demonstrate my case here. I cannot add hundred of my sound effects from my game here, you see. These musics being used as sound effects here are like substitutes of hundreds of my sound effects. In my project, all musics are streamed.

I do understand the complication of unloading sounds. But all these unloadable sounds make my project shoot up to 900 MB in RAM in the end when I visited all layouts. (Removing audio object entirely and I got only 300 MB) And more sounds are coming to the project. This is a matter of unreleased memory and it becomes a concern for bigger project.

For deallocating sound, I understand regarding that suddenly loading a sound could lead to a brief pause as the program need to decompress and allocate once again. However, we could just add all the preloads and unloads on all sounds that will be played on this layout, on the start and end of layout to make audio a smoother experience. In fact, this is what people should be doing anyway.

I do understand that deallocating resources could be a pain to implement, but it is mandatory for running a project with a large number of sound effects.

And thank you for your explanation regarding Working Set on another thread. It really clears things up for me. I appreciate it.

Problem Description

Some sort of memory are not deallocated when Sprite objects are no longer presented.

Attach a Capx

http://www.mediafire.com/download/k4fq5gq1r22wj1w/spriteLeak.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.

Observed Result

Test on Firefox:

Figure 1

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:

Figure 2

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:

Figure 3

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)

1 sprite:

Figure 4

5 sprites:

Figure 5

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:

Preview Chrome:

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?

Expected Result

No longer required memory should be released.

Affected Browsers

• Chrome: YES
• FireFox: YES
• Node Webkit: YES

Operating System and Service Pack

Win 7 64 bits Service Pack 1

Construct 2 Version ID

r173

Problem Description

Audio object does not release resources.

Attach a Capx

http://www.mediafire.com/download/dqltl5d4q2q1697/audioLeak.capx

Description of Capx

To demonstrate my point, capx contains 8 sound effects (they are actually long audio music files)

Steps to Reproduce Bug

• 1. Run your memory monitor program such as Performance Monitor.
• 2. run capx
• 3. Press Q,W,E,R,T,Y,U,I to load and play 8 musics.
• 4. Press S to stop music. Press 1,2,3 to go other layouts if you wish.
• 5. You will see on the memory graph that loaded sounds are never released. There could be some small fluctuation of memory given the nature of Garbage Collector. Nevertheless, you will see the memory size will never drop down to where it was when it was first loaded.

Observed Result

Audio does not release memory. I have tested this in Node Webkit, Chrome and Firefox.

Here is memory consumption for Node Webkit. The graph rises up in the beginning because of the 8 music, but it never come back down.

This here is for Firefox. The beginning is cut off, but the result is identical.

I have tested this several times and I have also tried waiting for 30 minutes after changing layout to Layout 3. (Press 1,2,3 to change Layout in capx above) Memory did not go down, and Layout 3 is just a blank layout.

Expected Result

I think there should be a way for Audio object to release unused audio.

Imagine a game where each stage is themed. (ie. forest stage got wild animals sound, city stage got traffic sound, etc.) Currently, our project got 140 sound effects and about 20 musics. We have tried removing Audio object out entirely, and played through the whole game. The memory consumption is 300-400 MB after every layout has been visited. With Audio, the sounds are preloaded and played in each layout and when all layouts are visited, we got 800-900 MB. Many more audio are also coming on its way to this project, and we are afraid that with unloadable audio, this could exceed 2 GB or even more in the future. Not to mention that we also got other resources that require memory as well. Obviously, it is mandatory that we must be able to free those animal sounds when we are in the city stage and vice versa. If C2 can deallocate texture memory, then why not audio as well?

Since Web Audio API is also Javascript, is it possible to tell the Web Audio API that certain resources can now be released? This is so Garbage Collector can collect the no longer required audio? Can anything be done here to release these resources?

Affected Browsers

• Chrome: YES
• FireFox: YES
• Node Webkit: YES

Operating System and Service Pack

Win7 64 bits Service Pack 1

Construct 2 Version ID

r173

This is a continued from

I found something:

Problem Description

The issues are as follow:

1. Memory Leak: save game causes memory leak in Chrome and Node Webkit.

2. Firefox: using dictionary and save game OR sometimes just save game alone cause javascript error.

Attach a Capx

http://www.mediafire.com/download/mdp5q5h56zznj15/testSaveLeak.capx

Description of Capx

The capx has 2 layouts and each of them has an event sheet that includes the main event sheet. Hold space to rapidly change between these two layouts. The reason is to demonstrate that save game on start of layout leaves memory leak.

Steps to Reproduce Bug

• Step 1: you need Performance Monitor tool or any tool that could measure memory consumption over time.
• Step 2: run the capx on preview Chrome and/or exported Node Webkit.
• Step 3: hold space bar to rapidly changing between layout 1 and 2 for about 10 seconds. You should see a spike in memory consumption.
• Step 4: now wait. Wait for a while, and you should see the memory consumption coming half way down. Wait longer and you will see that memory didn't go down further. Give it roughly 15 minutes to see whether garbage collector can do its job. See Figure 1 below.
• Step EXTRA: you can repeat step 3 and 4 and you will see memory consumption goes up and only come half way down again. See Figure 2,3,4.
• Step 5: Try disable save game statement in capx and run capx again.
• Step 6: do step 3 this time, and you will see memory does come down to almost initial value. See Figure 6.

Both Chrome and Node Webkit yield identical result. See Figure 5.

For Firefox, the issue is different. If you run the capx, you got a javascript error. See Figure 7. However, sometimes, I disabled dictionary add keys action and it runs fine. But sometimes it does not. In our game, we also run into this issue on Firefox, but if we do not save game, this does not occur.

Observed Result

There seems to be a memory leak in Save game function.

----------

Figure 1: by holding space for 10 seconds, memory consumption goes up, but eventually it dropped down to only half way for the rest of the time.

----------

Depending on Garbage Collector, sometimes memory would not come down immediately as well, but eventually it will come down, but only half way. Figure 2, 3, 4 below are from the same run:

Figure 2: holding space bar and memory stays up.

----------

Figure 3: after a while, memory consumption drops to half way.

----------

Figure 4: holding space bar again, and you see the curve goes up again and then come down to half

Note that Figure 1-4 are all Node Webkits.

----------

Figure 5: I see that both Chrome (purple line) and Node Webkit (blue line) have pretty much identical result. They go up but never come down more than half way. For Chrome, I hold space twice so that's why it goes up twice.

Another interesting thing to note is that Chrome has the gradually increasing memory consumption at constant after holding down space. From my previous post in another thread, I have also observed this behavior also holds true in Node Webkit. But whether this occurs or not could be random. In my game, memory keeps on going up like in Chrome in this case, when it is running in Node Webkit.

Figure 6: this shows what happened when save game has been toggled disabled. I hold space bar down twice, so you see two spikes here. The memory spiked up but eventually both of them get back down to initial memory value. This is in Node Webkit, by the way.

Figure 7: running capx on firefox yields the javascript error above.

Expected Result

There should not be memory leak when using save game.

Firefox should also not have javascript error.

Affected Browsers

• Chrome Version 36.0.1985.143 m: YES
• FireFox 31.0: YES
• Node Webkit (exported from r173) : YES

Operating System and Service Pack

Win7 64 bits Service Pack 1

Construct 2 Version ID

r173

This is a smaller scale bug reproduction. The save file for this capx is rather small ~40 KB, but in our game, our save file goes up to 700 KB, and as we play on and on, our memory hits 800 MB in less than an hour, and it just never gets back down at all. Sure, there are other factors such as more events, objects, etc. But also recall from figure 5 above, our app in Node Webkit has that gradually increasing memory behavior after playing the game for a while, and at that time, we already leave it untouched - no new objects created, etc., yet memory still goes up. (this is also discussed in )

Could you please investigate what went wrong in the save game function?

For us though, we are making a game on Node Webkit, so we would be grateful if you could focus on chromium side first. In fact, we do not really care about the Firefox issue. It's the Node Webkit / Chrome issue that is our major concern right now.

I need tools for inspecting memory leak in my app.

I am developing an app with r173, and I see that it got some sort of memory leak in node webkit. After some more investigation, I somehow have a feeling that this actually could be Chromium engine's fault. But I am not sure yet.

I have used Performance Monitor to see the growth of memory of my app when using Node Webkit, Chrome, and Firefox:

These 2 graphs here are Chrome. The memory just keep on shooting up. Node Webkit starts out consuming lower memory but it also keeps on increasing no different than Chrome. Obviously, they used the same engine.

On another instance, I have also monitor for 15 mins and you can see that it already shoots beyond 500K mem.

This graph below is Firefox. It fluctuates a lot, but memory consumption seems to come back down to a reasonable size. The huge spike there was caused by me rapidly restarting the same layout over and over. I did the same to Chrome, but it does a little longer for the curve to come back down. (not shown here)

I have tested that if I stay still in a layout and didn't change layout at all, memory would stay in the reasonable range. When I change the layout and stay still in the new layout, somehow memory gradually starts increasing. I have been trying to reproduce the memory leak on a smaller scale capx, but I couldn't reproduce it at all for the passed few days.

So I have been trying to narrow down what could cause this in my app. One of them is that if I add several keys into a Dictionary on start of layout, a leak would occur, if I restart layout several times. (memory gradually going up) I have tried disabled that dictionary out, and doing nothing in one layout, and restarting layout several times, I see that memory goes up and down ok, and not gradually going up. I tested this for several times, and I got more or less identical results. However, when I change to another layout, I see memory gradually going up again. It still goes up even no new objects are created. I see the graph rises up slowly as if something new is created and added to the memory all the time.

Here is one of my tests: I have created an empty layout with only one event that allows me to get back into the game. There are no objects at all, except for... maybe global dictionaries/arrays. I got the following test result:

a. starting out in layout A. Doing nothing. Memory dropped.

b. change to layout B. Memory rising cuz of new objects, etc. memory still dropped down a bit.

c. change to blank layout. Memory dropped twice.

d. change back to layout A, and restart the layout about 10 times.

e. change to blank layout again.

f. change back to layout A.

From e. onward, you will see that memory keeps on slowly increasing non-stop.

Could this mean Garbage Collector is too slow to collect garbages? The gradually increasing graph does imply that some culprits are not freed and accumulating. But the result from e. and f. also made me worried and wonder whether Garbage Collector stopped working entirely. I used to see my app went up to 800 MB and still increasing, in just an hour or so. At that time, the game starts to stutter a bit at ~50 fps instead of flawless 60 fps.

Whatever the case, I am looking for a tool to inspect which component(s) could cause memory leak. This is difficult to report to the node webkit and chrome folks because I could not reproduce this on a smaller scale capx. If I could know which component does this, I could create the capx and export the node webkit to the developers.

Ashley, do you appear to know any tools or the like? Any help is appreciated.

Problem Description

audio playback time is not updated when playing the second music with the same audio tag after the first music has already stopped.

Attach a Capx

https://www.mediafire.com/?oks90u0lr040tlo

Description of Capx

The capx has all the events to reproduce this bug.

Press Q to play music 1.

Press W to play music 2.

Press E to play music 3.

All musics are played with tag "music".

Press S to stop tag "music".

Steps to Reproduce Bug

• Press Q to play music 1.
• Now, press S to stop.
• Press W to play music 2.
• You will see that the Audio.PlaybackTime("music") is frozen, when music 2 is playing.

Observed Result

After playing and stopping music 1, Audio.PlaybackTime("music") is frozen when music 2 or 3 is played. However, if we stop and play music 1 again, Audio.PlaybackTime("music") will yield correct result, start counting from 0. Only the first music played can retrieve the playback time from Audio.PlaybackTime("music").

Expected Result

Audio.PlaybackTime("music") should return playback time of the new playing music, given that the previous music has already stopped.

Affected Browsers

• Chrome: YES
• FireFox: YES

Operating System and Service Pack

Win7 64 bits

Construct 2 Version ID

r173

Hey, Ashley, thank you for your suggestion. It does fixed this issue. Incorrect object count is also no longer an issue as well.

Thank you for your assistance as always.