Memory usage. Any difference between methods?

Discussion and feedback on Construct 2

Post » Thu Jan 19, 2017 8:49 pm

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?
B
61
S
20
G
56
Posts: 1,077
Reputation: 35,991

Post » Thu Jan 19, 2017 9:47 pm

There's no real difference. 9 sprites at 1200x700 is terrible for memory no matter what you do.
Image ImageImage
B
170
S
50
G
179
Posts: 8,378
Reputation: 113,425

Post » Fri Jan 20, 2017 4:18 am

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.
B
61
S
20
G
56
Posts: 1,077
Reputation: 35,991

Post » Fri Jan 20, 2017 4:38 am

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.
ImageImageImage
B
27
S
16
G
82
Posts: 1,029
Reputation: 45,777

Post » Fri Jan 20, 2017 4:57 am

@BackendFreak 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.
B
61
S
20
G
56
Posts: 1,077
Reputation: 35,991

Post » Fri Jan 20, 2017 6:26 am

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".
Image ImageImage
B
170
S
50
G
179
Posts: 8,378
Reputation: 113,425

Post » Fri Jan 20, 2017 11:59 am

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.
Scirra Founder
B
399
S
236
G
89
Posts: 24,519
Reputation: 195,351

Post » Fri Jan 20, 2017 2:12 pm

Ashley wrote: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?
ImageImageImage
B
27
S
16
G
82
Posts: 1,029
Reputation: 45,777

Post » Fri Jan 20, 2017 2:33 pm

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.
Scirra Founder
B
399
S
236
G
89
Posts: 24,519
Reputation: 195,351

Post » Fri Jan 20, 2017 2:47 pm

Alright, it's clear now. Thanks for the info.
ImageImageImage
B
27
S
16
G
82
Posts: 1,029
Reputation: 45,777

Next

Return to Construct 2 General

Who is online

Users browsing this forum: No registered users and 6 guests