Not releasing texture memory on data.unload()
10 August 2017 03:11
I'm working on an application that has several environments which are swapped in and out by calls to data.unload() and data.load(). This is working except that b4w doesn't seem to be releasing texture memory when an environment is unloaded. Debugging the memory usage shows it increasing as new scenes are loaded, but not decreasing when they are unloaded. This is causing browsers on some mobile devices to crash once they've swapped between several environments. Any ideas on what might be causing this?
10 August 2017 11:38
11 August 2017 14:51
I've put together a simple project that reproduces the issue. You can download it here: https://drive.google.com/open?id=0B_nuwEOI7MTkQlp0S0RsdmExSXc
The issue is specifically occurring on the IPhone 6 on safari, it may be ocurring on other browsers as well. There are three scenes with different textures, click the buttons to change the scenes. I'm writing out the amount of consumed texture memory as reported by blend4web which appears to be fine, but if you inspect the amount of memory consumed on the device in the safari dev tools it keeps increasing as the scenes are swapped. Eventually when the memory consumption is high enough it will crash the browser and the site is reloaded.
Also just to note these aren't the textures or environments I'm using in our application, I just chose these large textures to show the issue.
The issue is specifically occurring on the IPhone 6 on safari, it may be ocurring on other browsers as well. There are three scenes with different textures, click the buttons to change the scenes. I'm writing out the amount of consumed texture memory as reported by blend4web which appears to be fine, but if you inspect the amount of memory consumed on the device in the safari dev tools it keeps increasing as the scenes are swapped. Eventually when the memory consumption is high enough it will crash the browser and the site is reloaded.
Also just to note these aren't the textures or environments I'm using in our application, I just chose these large textures to show the issue.
11 August 2017 20:15
12 August 2017 15:39
14 August 2017 10:39
Are you able to give an estimate for when you may be able to look into it and potentially submit a fix?Probably this or next week. We will try to fix it before the upcoming 17.08 release, which is planned at the end of this month. Also, the update for 17.06 LTS should come out a bit earlier.
18 August 2017 16:37
Hi, yes we've managed to found the reason of these memory leaks and have already fixed it. It's most likely that we will release LTS 17.06.3 today with this fix included.
Let me explain it a bit: this bug was related to a texture cache that the engine uses for dynamically loaded scenes to speed up the loading of the same resources (this is especially noticeable, when swapping through the same several scenes multiple times). This cache suffered from memory leaks and just failed to work in some cases. Now, with the mentioned fix you should be able to load scenes in the test project you attached above without crashing.
BUT, the cache still can grow, of course not so excessively as before the fix, but it can. It perfectly suits for configurator applications with the limited amount of resources, but if you need to load/unload many big and different scenes, e.g. different locations, game levels or something similar you should consider disabling the cache at all. For this reason we've also added the configuration parameter "enable_texture_cache", which you can set to "false" and pass into the app.init() method along with others.
Let me explain it a bit: this bug was related to a texture cache that the engine uses for dynamically loaded scenes to speed up the loading of the same resources (this is especially noticeable, when swapping through the same several scenes multiple times). This cache suffered from memory leaks and just failed to work in some cases. Now, with the mentioned fix you should be able to load scenes in the test project you attached above without crashing.
BUT, the cache still can grow, of course not so excessively as before the fix, but it can. It perfectly suits for configurator applications with the limited amount of resources, but if you need to load/unload many big and different scenes, e.g. different locations, game levels or something similar you should consider disabling the cache at all. For this reason we've also added the configuration parameter "enable_texture_cache", which you can set to "false" and pass into the app.init() method along with others.