Memory usage. Any difference between methods?

I have a slideshow that I am displaying. It is made up of 9 sprites about 1200x700 in size. Currently what I'm doing is creating the first sprite which has a fade behavior attached to it. The images don't actually fade, they simply are destroyed after the behaviors wait time ends. When the first sprite is destroyed the second sprite is created and so on. I am wondering if there are any advantages or disadvantages of this method over simply creating one sprite with 9 animation frames and destroy the sprite after the animation is finished playing?

There's no real difference. 9 sprites at 1200x700 is terrible for memory no matter what you do.

Yes, you're absolutely correct about it being terrible for memory. I was hoping there might be some advantage of doing one way over another though. I know a couple techniques to get the memory numbers down by about 85-90% or so but I don't think it would be worth the time for something like a 1 minute slideshow that will only ever be played on a PC anyways. Thank you for your reply, I appreciate it.

There is a difference.

If you put all images into one sprite as an animation then all images will get loaded into the memory at the start of the layout together with the sprite object.

If you put each image into separate sprite and those sprites are not on the layout by default but are created one after another as you described (note that you need to have them on some separate layout to be able to create them with System -> Create object). Then initial memory usage will be lower as no images will be loaded.

Now by creating a particular sprite you will load its image into memory. By destroying the sprite you are dropping the object's reference which is like a "you can take it away" flag for JavaScript GarbageCollector.

The point is that there is no way to manually call the GC in JS, so if it happens that GC comes when you're watching 5th slide for instance, then it will release first four images from the memory as they are destroyed and nothing is pointing at this part of the memory any more. But GC may also not come during the whole slideshow. So this approach takes less memory initially and may take less in general, but it's not 100% promised... depends on GC.

— Thank you for your reply. That was the idea I had when I put the slideshow together that way in the first place so I'm glad to hear it. I think I will end up keeping it as is for now. If any issues come up, which I don't expect, I'll probably end up just using a better method rather then running the slides as a single animation.

Well if you aren't worried about load time hang then you could just load via url and have all the textures as project files.

Ajax would add asynchronous calls so that you don't have "dead air".

If you use separate sprites, and put each sprite on its own layout, the C2 engine will only load one at a time.

The WebGL texture memory is explicitly released by the engine - GC does not play a part.

If you use separate sprites, and put each sprite on its own layout, the C2 engine will only load one at a time.

The WebGL texture memory is explicitly released by the engine - GC does not play a part.

Oh so it's handled differently than sounds. Good to know thanks. Also could you tell if the image/sprite buffer is released from the memory instantly once the object gets destroyed or after switching layout?

I know that you wrote in the article about memory that it gets released from the memory after layout switch (if it doesn't exists on the next layout), but I'm not sure if it's about the sprites which are on the layout till the layout switch or does that rule fit sprites destroyed during layout as well?

WebGL texture memory is created and released instantly by the engine itself. It only updates when changing layout, so if you destroy all instances of an object, they are kept in memory (on the assumption you may create more later on) until you change layout, at which point they are released so long as they're not also used on the next layout you're going to.

Memory management basically works by entire layouts. The engine tries to avoid creating or releasing textures while the game is running, since that can cause pretty bad jank.

Alright, it's clear now. Thanks for the info.

If you use separate sprites, and put each sprite on its own layout, the C2 engine will only load one at a time.

The WebGL texture memory is explicitly released by the engine - GC does not play a part.

Or, just go to the next layout. lol

Thank you everyone for the input. Learned something new which is always a good thing! I think switching each slide to it's own layout would be the easiest way to go in this instance for sure.