Excal - textures are loaded layout-by-layout when WebGL is supported.
0plus1 - WebGL shouldn't be loading everything on startup, how are you measuring that? If you can see VRAM increasing to unusually large levels maybe you should file a bug about it.
However I still disagree, Ejecta is at fault here. Browsers handle it perfectly fine, and if Ejecta's purpose is to allow you to port browser games to native, then it should act like a browser too.
Here's what Construct 2 does:
On startup, it creates an Image object for every object in the project, and assigns its src property. This tells the browser to download it. Browsers do *not* create a texture in memory yet, because they're smart. They either write the compressed PNG/JPEG to a disk cache, or leave the compressed file in memory if there's room. Most DOM-less engines (including CocoonJS) make the mistake of creating a texture as soon as you assign the src property. This means they crash before a real browser would have even created a single texture. Browsers only create a texture the first time you draw it.
When a layout starts:
- in the WebGL renderer, we explicitly create textures for objects that are on the layout.
- in the canvas2D renderer, we draw every image for each object that is on the layout in an invisible way. Since browsers create a texture the first time it's drawn, this effectively pre-loads all textures for canvas2D, and avoids "janking" (pausing as images are loaded mid-game).
When a layout ends:
- in the WebGL renderer, we explicitly free textures for objects that are on the previous layout and not on the next layout.
- in the canvas2D renderer, there's nothing we can do, it doesn't provide a way to say "release this texture" (yet, anyway). Luckily most browsers are also sufficiently smart that if they run out of memory trying to create a new texture, they'll go back, release a bunch of textures that haven't been drawn for a while, then try creating the texture again. It's a bit of a hack, but it does successfully prevent devices running out of memory as you move between lots of different large layouts.
The problem with a lot of DOM-less engines is they are naive, and do the dumb thing of creating textures as soon as the src is assigned. The solution is to make it do what browsers do.