As explained in the above mentioned blogpost, we offer many APIs which give developers even more precise memory control than standard browsers (like the immediate "dispose" method).
The "dispose" method does not solve the problem by itself. By the time you can call it, the image is already in memory, which means it might already have crashed, and it still unnecessarily loaded it which increases the loading time.
[quote:l5tfqw08]Construct2 loads all the assets at startup
No, it only downloads them. It's a web based engine after all and the game needs to be downloaded before starting. CocoonJS is unique in going ahead and decompressing everything in to memory when we only wanted to download. In a local app, since there is nothing to download, it should simply amount to "remember the path".
[quote:l5tfqw08]Canvas+ just loads an image when the "src" property is set from JavaScript
This is precisely the problem: in browsers that is the directive to download a resource.
[quote:l5tfqw08]The entire team agrees that preloaded OpenGL textures make HTML5 games feel more native-like. Reading an image from disk and uploading a texture to the GPU is an expensive operation, which may lead to noticeable glitches or pauses if the process is carried out in the middle of a render animation.
The key problem is all browsers disagree with you, even mobile browsers. Anyone designing any web-based engine must deal with the fact that all browsers will have precisely that problem with lazy-loading causing jank mid-game. Therefore, anyone with interest in designing an engine that works well on real browsers will have already mitigated that problem. Construct 2 has done exactly this, by some pre-rendering code before start of layout in canvas2d mode, and texture creation in WebGL mode. This brings a smooth, native-like feel to real browsers even though they lazy-load resources. By choosing a different approach, CocoonJS creates two problems:
1) our approach, designed for real browsers, doesn't work, nor will any other engine which has similarly mitigated the problem for real browsers
2) anyone designing a game for CocoonJS, then porting it to a real browser, will find it suddenly suffers from mid-game jank due to lazy loading resources the first time they are used.
So I'd have thought it would actually be favourable to CocoonJS to copy what the browsers do and provide advice on how to work around lazy loading in a portable, cross-platform manner. This solves both problems.
I think the key problem is that you perceive this change as some kind of performance improvement, whereas really it throws a spanner in the works of any engine that's already designed for real browsers, and will trip up anyone porting their game either to or from CocoonJS.
[quote:l5tfqw08]That’s why we are going to keep this approach as the default in Canvas+. Do you prefer the other approach? We have added the "cocoonLazyLoad" property to enable it. Just use the one that works better for you.
At last! I'll add that in as the default for images the next build. But as argued above, I feel this ought to be the default!
[quote:l5tfqw08]Surprise, Construct2 running with WebGL eats almost twice the memory on WebView than on Canvas+.
I think all this proves is the WebView has a full browser engine (including features like DOM, web audio API, WebRTC etc), and a full browser engine takes up a bit more memory.
[quote:l5tfqw08]It seems that Images are not properly released specially on Canvas+ even if the capx uses layout by layout. Inspecting the code with Google Chrome profiler we have found that Image references are strongly retained in the Construct2 engine and are not disposed of (when using canvas2D context). This is bad for the garbage collector.
It shouldn't matter, because in real browsers holding a Javascript reference to an Image object does not mean the Image is decompressed in memory. We can't drop the reference, because we might need it again if the player comes back to that layout later. If we drop references and re-create them we might invoke downloads in real browsers, wasting bandwidth and causing delays, and a separate codepath also defeats the point of having a portable engine that runs the same everywhere. To me your graph simply identifies the canvas+ bug.
I'd also point out that it's sometimes difficult to make good sense of garbage-collected memory use graphs, since they can spike high and appear to be using lots of memory, but the next collection is able to release it all. That's an essential point: it is more important that it can release memory when it's high, than how much the highest memory use actually is. This allows the game to continue running as opposed to crash, as evidenced by the larger games which tend to crash when ported to Canvas+ when they run fine in a real browser (even with higher memory use!). The 2nd graph also confirms this: despite peaking higher, the web view finishes with lower memory use than canvas+. So I don't consider the peak memory usage particularly relevant, a more important question is "does it crash?"