Bloated memory use after import from C2 to C3

Hey everyone,

I'm converting a C2 project to C3 and I've solved most of the little bugs it created. However I've noticed the (estimated) image memory used you can see in the NW.js debugger has inflated by 50% in the process. I noticed the Runtime used also impacts this value.

Here is the debugger from C2 : 194.4mb

Here is the debugger from C3 (with C2 runtime) : 243.9mb

Finally here is the debugger from C3 (with C3 runtime) : 313.4mb

Is it a known issue or should I a file a bug report ?

Mobile is not a primary target platform but I plan to release the game there in the future, so memory issues can be a big deal.

I've found this report that's kinda similar but the problem was apparently spritesheets being sometimes bigger than 2048*2048 and there's no object in my project that's even close to being 2048 pixels wide.

github.com/Scirra/Construct-3-bugs/issues/2094

Thanks in advance for your opinions :)

Construct 3 uses a different spritesheeting algorithm. It can result in better performance but in some cases uses a bit more memory. You can customise it by changing the max spritesheet size setting in advanced project properties.

Thank you Ashley. If you don't think it is alarming then I won't dig too much into it. I'll test my game again on older configurations and see if the performance/memory tradeoff is problematic or not :)

Investigating a little more I think I bumped into the problem, and to me it seems reaaaaaally severe.

Here is a test case for both C2 and C3 :

https://www.mediafire.com/file/b3ij98kz87g6luq/ConstructMemoryProblemCase.7z/file

In each of the projects, I have 8 sprites of the size 800px*800px.

In C2

If you create these sprites on an empty layer one by one, the memory progressively increases. From base 6.6mb to 9mb to 11.5mb etc... That's around 2.5mb per sprite added.

If you restart the layout, the memory is purged and you go back down to 6.6mn.

In C3

• C3 groups the sprites into spritesheets of 2048*2048, and these can hold 4 sprites of 800px*800px at a time. Clicking Tools >> View Spritesheets you can see Sprites 1 to 4 are together and 5 to 8 are together.
• if you create sprite1 on an empty layer the memory increases by a massive amount, from 2mb to 18mb right away!
• try to create sprite2 and... the memory doesn't budge.
• try to create sprite5 (which is on the second spritesheet) and the memory jumps again to 34mb.

==> conclusion : C3 loads the ENTIRE spritesheet containing a needed sprite, even if the other sprites inside are not needed. That's a massive waste of memory if you ask me!

Even trying to unload unused memory manually won't change this memory load.

It is a very big problem and I really don't think it's intentional.

• Another problem : If you restart the layout... the memory stays the same even though the sprites are not here anymore ! You have to manually purge the memory using the system action "Unload Unused Images from Memory".

==> memory is not automatically purged on start of layout!

This to me seems like another very big problem that didn't exist in C2.

I hope I'm doing something wrong because these would be fundamental problems for the image memory management system, wouldn't they? I reproduced the case easily with a basic project, so that convinced me the problems I first encountered weren't related to the fact I was trying to convert a pretty big project from C2 to C3.

Thanks in advance for your opinions on the matter. If I need to write a bug ticket, I can, just tell me.

Thank you again Ashley for your quick answers :)

1) Spritesheeting

Ok so this spritesheeting is normal behavior... I don't question its general usefulness, but it feels kinda counterproductive in certain instances, especially when it groups objects that are never meant to appear together. Sometimes the algorithm doesn't have a choice to do so I understand, but still.

For example in my project I used to have a sprite with 100 frames of 800x800 (reprensenting a whopping 300mb by itself), but since there would always only be one that'd be used per layout I splitted it in a hundred sprites 800x800 instead.

With the spritesheeting this optimization is diminished since the game needs to load at least a spritesheet each time, which represents 4 sprites (3 being useless).

It's probably not feasible, but since we can consult the Spritesheets it would be great to be allowed to isolate one or more sprites, effectively saying : "these must not be grouped with other sprites". That would save a lot of image memory and enable anyone to build their own Performance/Memory Scale sort of.

Maybe it's not that big a deal on desktop, although it probably depends on the project, but I suppose for mobile it wouldn't be negligible?

2) No purge at new layout

I read and re-read the layout-by-layout memory management page, and the simple test I produced directly contradicts it. Supposedly :

When the layout ends, all images that are loaded but not used on the next layout are released from memory.

If an object is not placed in the layout view, but events create it at runtime, its images are not pre-loaded.

In the example I linked, after you've created sprites through events that bump the memory usage from 2mb to 34mb, restarting the layout should purge the memory back to 2mb since they are not on the next layout. And it's not the case, it stays at 34mb and memory must be purged manually :x

I did, but the memory won't decrease back so much, plus that means giving up on the performance improvements Ashley said were linked to bigger spritesheets :x

But if this lack of flexibility is voluntary I'll be moving on and I won't bother you with more questions.

What about the absence of automatic purge at layout restart though ? I can't help but think it contradicts the manual.