Howdy, Stranger!
It looks like you're new here. If you want to get involved, click one of these buttons!
Quick Links
Categories
- 7.8K All Categories
- 11 Help with translations
- 4.2K General questions
- 107 Roadmap
- 358 Game & application design
- 316 Plugins
- 70 User experience
- 75 Marketplace
- 291 Code snippets
- 34 Building a team?
- 269 Suggestions & requests
- 352 Announce your apps made with Gideros.
- 90 Step by step tutorials
- 668 Bugs and issues
- 195 Introduce yourself
- 239 Announcements
- 106 Forum talk
- 404 Relax cafe
Windows player crashes, and freeing texture memory
PaulH
Member
Folks,
I’ve been experiencing crashes of the Gideros player on Windows when running resource-heavy apps, especially with newer versions of Gideros, and finally took some time to try to understand why. It appears the current player doesn’t always free texture memory during garbage collection, or even between separate runs of an app within the player.
I saw the post http://forum.giderosmobile.com/discussion/8230/code-optimization-gideros-player-crash which describes the player crashing when a very large number of Sprites are created, and that could be a factor in crashes I'm seeing with the new game I’m working on, but I’m also seeing player crashes when running a project that creates very few but very large sprites.
What I’m noticing is that texture memory doesn’t seem to be freed by collectgarbage(), or even between runs of apps on the current player. An app might run fine several times on the player, and then crash the player, without any message in the output of the studio. I’m using Windows 10 on a PC with 32 GB of RAM.
I’ve put together a stripped down version of one of my utility programs that can repeat the crashes. The purpose of the code is to make animation frames for seamless loops from frames taken from moving video. It loads a bunch of full HD (1920 x 1080) textures and blends them onto render targets, and saves the resulting textures. The code includes periodic calls to collectgarbage, but between those calls it may load or create 39 of those big textures. Yes, that’s a lot of texture memory, hundreds of MB. I could do a lot to make it more efficient and reduce its memory requirement, but since this is a utility used only in-house on a PC, there’s been no need to do that.
All the textures and Sprites using them are in local variables within functions, and never added to globals or the stage, so I’d expect garbage collection to recover all that memory. Then the code repeats all of those steps (including garbage collection.) In the case of my stripped down sample, it does this 7 times with different textures.
The code works, but not repeatedly on the same player instance. Windows task manager shows the player using 64 MB before I run the app, then climbing to 1.3 GB. If I run it again, the player starts with 1.3 GB of memory being used, and climbs from there, and the player will crash.
If I use Gideros 2019.12 and run the same app, the player starts out using 39 MB, and peaks at about 69 MB, then drops to 61 MB at the end of the run. If I run again it peaks at 94 MB, then drops back to 61 MB. I can run the app repeatedly without the player crashing or increasing its memory usage beyond 94 MB. The fact that it peaks at only 94 MB, when it has used over 300 MB of textures in each of the 7 passes, suggests that automatic garbage collection has dealt with most of the texture memory even before I call collectgarbage(). I tried without calling collectgarbage(), and I see the same memory usage, so that’s more evidence that the automatic garbage collection is freeing up orphaned texture memory quite nicely.
I’ve uploaded the project in question to http://www.pishtech.com/player_memory_issue.zip.
Here’s a simpler test: Create a new project with a single line of code that loads a 1920 x 1080 pixel texture. If I do that in Gideros 2019.12, the memory usage of the player increases by 750 KB each time I run it. The same thing in Gideros 2020.9 increases the memory usage of the player by 6.3 MB with each run, the equivalent of 24 bits per pixel in the texture.
That suggests that there’s a little memory left unrecovered in the player between app runs even in older versions of Gideros, but that now it may be failing to recover most or all of the memory used when initially loading a texture from a file.
I'm hoping this is just an issue in the Windows player, in which case it's just a minor annoyance of having to restart the player now and then. But if the issue lies in the Gideros code itself, might it explain some mysterious crashes in published apps too?
Paul
I’ve been experiencing crashes of the Gideros player on Windows when running resource-heavy apps, especially with newer versions of Gideros, and finally took some time to try to understand why. It appears the current player doesn’t always free texture memory during garbage collection, or even between separate runs of an app within the player.
I saw the post http://forum.giderosmobile.com/discussion/8230/code-optimization-gideros-player-crash which describes the player crashing when a very large number of Sprites are created, and that could be a factor in crashes I'm seeing with the new game I’m working on, but I’m also seeing player crashes when running a project that creates very few but very large sprites.
What I’m noticing is that texture memory doesn’t seem to be freed by collectgarbage(), or even between runs of apps on the current player. An app might run fine several times on the player, and then crash the player, without any message in the output of the studio. I’m using Windows 10 on a PC with 32 GB of RAM.
I’ve put together a stripped down version of one of my utility programs that can repeat the crashes. The purpose of the code is to make animation frames for seamless loops from frames taken from moving video. It loads a bunch of full HD (1920 x 1080) textures and blends them onto render targets, and saves the resulting textures. The code includes periodic calls to collectgarbage, but between those calls it may load or create 39 of those big textures. Yes, that’s a lot of texture memory, hundreds of MB. I could do a lot to make it more efficient and reduce its memory requirement, but since this is a utility used only in-house on a PC, there’s been no need to do that.
All the textures and Sprites using them are in local variables within functions, and never added to globals or the stage, so I’d expect garbage collection to recover all that memory. Then the code repeats all of those steps (including garbage collection.) In the case of my stripped down sample, it does this 7 times with different textures.
The code works, but not repeatedly on the same player instance. Windows task manager shows the player using 64 MB before I run the app, then climbing to 1.3 GB. If I run it again, the player starts with 1.3 GB of memory being used, and climbs from there, and the player will crash.
If I use Gideros 2019.12 and run the same app, the player starts out using 39 MB, and peaks at about 69 MB, then drops to 61 MB at the end of the run. If I run again it peaks at 94 MB, then drops back to 61 MB. I can run the app repeatedly without the player crashing or increasing its memory usage beyond 94 MB. The fact that it peaks at only 94 MB, when it has used over 300 MB of textures in each of the 7 passes, suggests that automatic garbage collection has dealt with most of the texture memory even before I call collectgarbage(). I tried without calling collectgarbage(), and I see the same memory usage, so that’s more evidence that the automatic garbage collection is freeing up orphaned texture memory quite nicely.
I’ve uploaded the project in question to http://www.pishtech.com/player_memory_issue.zip.
Here’s a simpler test: Create a new project with a single line of code that loads a 1920 x 1080 pixel texture. If I do that in Gideros 2019.12, the memory usage of the player increases by 750 KB each time I run it. The same thing in Gideros 2020.9 increases the memory usage of the player by 6.3 MB with each run, the equivalent of 24 bits per pixel in the texture.
That suggests that there’s a little memory left unrecovered in the player between app runs even in older versions of Gideros, but that now it may be failing to recover most or all of the memory used when initially loading a texture from a file.
I'm hoping this is just an issue in the Windows player, in which case it's just a minor annoyance of having to restart the player now and then. But if the issue lies in the Gideros code itself, might it explain some mysterious crashes in published apps too?
Paul
Likes: MoKaLux, SinisterSoft, hgy29
+1 -1 (+3 / -0 )Share on Facebook
Comments
Likes: SinisterSoft
Likes: SinisterSoft, antix
Likes: MoKaLux, SinisterSoft
Fragmenter - animated loop machine and IKONOMIKON - the memory game
Dislikes: SinisterSoft
Fragmenter - animated loop machine and IKONOMIKON - the memory game
Likes: keszegh, SinisterSoft, talis
Likes: MoKaLux, SinisterSoft
Fragmenter - animated loop machine and IKONOMIKON - the memory game
Likes: MoKaLux, antix
Fragmenter - animated loop machine and IKONOMIKON - the memory game
Likes: SinisterSoft, MoKaLux
There still seems to be a small leak (750 KB in the example) each time the app is run. In a fairly memory intensive game I'm seeing a leak of about 1.25 MB per run. That's not a significant issue, at least for me.
Likes: MoKaLux