Pixi.js: Out of memory chomre when loading 200k sprite ?

Created on 29 Dec 2018  Â·  10Comments  Â·  Source: pixijs/pixi.js

I am using ParticleContainer to load 200k sprite object with image texture is 1KB. The chrome crash after memory inscrease to 2GB. Why my memory inscrease so much ? I see bunnymarker performance test with 100k sprite and no crash. Are there any problem in here ? Below is my algorithm:

create ParticalContainer
for(1 to 200k) {
create sprite with texture
add srpite to particleContainer
}
render particleContainer

Most helpful comment

Unfortunately what I want to is do memory snapshots in chrome debug tools and see what is eating 2G of memory. I'd also like to experience the crash and look through logs. Since you can't share, all I can say is you should do some of those things to try and track down your issue.

Either way, you almost certainly don't need to be spawning 200k sprites. There is no way all of those sprites are shown on screen at the same time, and if they are you should be drawing it a different way. I'd only create sprites the user can see, then as they go off screen free them into a pool and as more come on screen get new ones from the pool (or create a new one). Never create more than the user can actually see/interact with.

All 10 comments

Which version is it?

4.8.2
On Sat, Dec 29, 2018 at 19:52 Ivan Popelyshev notifications@github.com
wrote:

Which version is it?

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/pixijs/pixi.js/issues/5314#issuecomment-450490975,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AJNGCWSToiQcq2V8rxtafQDxQeJiJEpPks5u92WOgaJpZM4ZkfIS
.

I guess there's something wrong with "autoResize" feature of particlecontainer.

Btw, I see that i forgot to remove that if, we need to add autoResize in condition: https://github.com/pixijs/pixi.js/blob/v4.x/src/particles/webgl/ParticleRenderer.js#L135

But it saves videomemory, not destroys it, so, your bug is different.

Can you share a running example that reproduces please? I'd like to see exactly what you are doing.

@englercj I cannot give you a running example because it is a part of application, hard to reproceduces, but i can share the part I draw items:

         this.container = new P.Container();
         const spriteContainer = new P.particles.ParticleContainer(markers.length, {
            position: true,
            rotation: true,
            scale: true,
            tint: true,
            vertices: true
          });;
          this.container.addChild(spriteContainer);
          markers.map((m: any) => {
            const coords = project(new LatLng(m.lat, m.long)); 
            const markerSprite: any = new P.Sprite(this.textures[markerName]);
            markerSprite.x = coords.x;
            markerSprite.y = coords.y;
            markerSprite.tint = colors[Math.floor(Math.random() * colors.length)];
            markerSprite.rotation = Math.PI / (Math.random() * 5 + 1);
            markerSprite.anchor.set(0.5, 0.53);
            markerSprite.scale.set(invScale);
           spriteContainer.addChild(markerSprite);
          });
          renderer.render(this.container)

Unfortunately what I want to is do memory snapshots in chrome debug tools and see what is eating 2G of memory. I'd also like to experience the crash and look through logs. Since you can't share, all I can say is you should do some of those things to try and track down your issue.

Either way, you almost certainly don't need to be spawning 200k sprites. There is no way all of those sprites are shown on screen at the same time, and if they are you should be drawing it a different way. I'd only create sprites the user can see, then as they go off screen free them into a pool and as more come on screen get new ones from the pool (or create a new one). Never create more than the user can actually see/interact with.

@englercj thanks for your suggestion

Closing this as I believe @englercj has offered a good explanation and suggestion.

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

neciszhang picture neciszhang  Â·  3Comments

SebastienFPRousseau picture SebastienFPRousseau  Â·  3Comments

sntiagomoreno picture sntiagomoreno  Â·  3Comments

softshape picture softshape  Â·  3Comments

courtneyvigo picture courtneyvigo  Â·  3Comments