[quote:13xpov47]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.
The dispose method is just an extension to provide a more precise control over the memory usage. Canvas+ also disposes unretained images when the Garbage Collector comes into action. On a WebGL context you can release a texture immediately, but you can’t do that on a Canvas2D context, and that’s a desirable feature. By not using dispose method on Canvas+ or cleaning up retained references on a real browser you are not giving a hint to the browser and you’re totally relying on the internal memory management heuristics. Immediate dispose or cleaning references is always better than letting the browser guess when it should dispose images.
Thanks to the dispose method some resource demanding games that crash (white screen) on a real webview were able to work on devices like the iPad 1.
[quote:13xpov47]This is precisely the problem: in browsers that is the directive to download a resource.
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.
Copying what a mobile browsers does was not our goal because they were not initially designed for gaming. That’s why Canvas+ came to life. Before the latest Android 4.4 or iOS 7.0+ webviews, a native-feel like game using a mobile webview was almost impossible, even using the tricks you are talking about. However, the native-feel like experience was easily achieved with Canvas+, which was specifically designed for gaming.
You might need the pre-rendering code to mitigate the mid-game janks of real browsers but that pre-rendering code just works on Canvas+. A blitting operation with preloaded textures is negligible in Canvas+, you don’t need to maintain two code bases.
The good news is that from CocoonJS 2.1 we support both approaches: preloaded textures or lazy loading. So any engine or user can choose the approach that works better for him. The real browser vs CocoonJS design issues that you are talking about are not a problem anymore.
[quote:13xpov47]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!
It’s already the default on C2 because we have added a duplicate called idtkLoadDisposed for retro compatibility with the current C2 version. But we like the cocoonLazyLoad name better. If you use the new one we will remove the other on a future release.
We would like to add a lazyLoad check into the CocoonJS C2 Plugin. Some users might want the old behaviour because C2 seems to have a problem showing progress bars when lazyLoading is enabled.
[quote:13xpov47]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.
It also proves that CocoonJS doesn’t deserve to be blamed for lack of memory management.
[quote:13xpov47]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.
It matters. We have created a testcase to show the difference on a real browser. You can drop image references. If you need them again just create a new Image object. A modern browser has advanced caching mechanisms, creates temporary files and is intelligent enough to avoid unneeded network downloads. The problem you are talking about is more negligible in mobile apps indeed. As all the assets are available locally, the browser doesn’t need to download anything from the network.
We have created a simple test to prove that retained images matter. You can download it from here: https://dl.dropboxusercontent.com/u/20744811/retain_testcase.zip
The test loads five 2048x2048 images, renders them during some seconds and then renders a red quad. In the first test we drop the images array, in the other one we don’t. The next graph shows the memory difference. Tested on the latest Safari Webview on a iPhone 5 running iOS 8.1:
In the first graph memory usage decreases when garbage collector comes into action, it takes some seconds to happen. In the second graph memory usage never decreases, because the browser can’t guess that the images will no longer be rendered and the garbage collector finds retained references. If the webview had the dispose method as Canvas+ does we could have decreased the memory amount immediately, without waiting for the seconds needed to the next garbage collector pass.
The conclusion (for Canvas2D contexts) is that dispose extension is the most effective way to decrease memory usage immediately. Dropping image references works at the expense of waiting for the next GC pass. Finally, keeping retained image references causes unneeded high memory usage until the browser enters in a dire situation and starts wiping out everything it can (similar behaviour can be achieved with the optional maxMemory feature in Canvas+)
Dropping image references in C2 might involve a bit of work but we really think that it would be a good improvement for both real browsers and CocoonJS. It might also help with the asset loading progress bar issue that some users are talking about. Anyway, the quickest solution is just to call dispose method if available when a layout changes (only one line of code).
[quote:13xpov47]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?"
That the WebView does not crash does not mean that a game will run. Webviews can die in high memory usage situations too. If the entire apps doesn’t crash is because some webviews (like the Chromium on Android 4.4) do the job on a separated process from the app. Is the same as what happens in Google Chrome. Each tab is a separate process and if one of them dies the Chrome app might remain alive.
We know that some customers were using the webview and the games were using so much memory that the webview just went blank. They started requesting the user to reboot the device and close all the other applications. We really think this is not the appropriate behaviour.
Thanks to these memory management tools we just released, we have been able to provide solutions for low memory devices. We strongly believe that mobile game development needs to move a bit away from this idea of "the browser will handle everything for me" and do a good memory management understanding the issues any native app always face. JavaScript and HTML5 are awesome but successful mobile deployment requires a bit more knowledge. We still read things like "it works on my desktop browser, it should work on CocoonJS Canvas+ or even any mobile browser" and that is a tricky statement.