Closed MorookaKotaro closed 2 years ago
Hi @MorookaKotaro,
Thanks for filing this issue.
I'm not sure if I understand your question correctly. Under the hood when a <Sprite>
component unmounts it will automatically be destroyed, see:
So I'm not quite sure where this memory leak is coming from, can you create a codesandbox demo with the memory leak with react-pixi? Thanks
On the other hand, in your code above the Sprite never gets destroyed because it will never unmount. Which is good.. you are only changing the texture.
It might be possible that there's something else happening in your code that's causing the memory leak?
Hello @inlet
Thank you for replying. Okay, I'll create react-pixi demo in a moment.
Sprite never gets destroyed because it will never unmount.
Yes, that's exactly what I was thinking. Since only the texture changes, Sprite will never unmount. Which means new Sprite object is created every time as the texture changes, though the older ones are not removed. That's why I was looking for the way to run destroy method manually.
Anyway, I'm going to create the demo!
Which means new Sprite object is created every time as the texture changes, though the older ones are not removed. That's why I was looking for the way to run destroy method manually.
Only 1 Sprite object will be created only the texture
member will be updated, same as sprite.texture = newTexture
@inlet
Hmm.. It seems working well with minimum demo... https://codesandbox.io/s/frosty-darkness-wvs8ds?file=/src/index.tsx
It could be my source code's fault. Sorry for opening a mistaken issue :_(
I'm going to investigate more, then I will contact you if anything founded.
Thank you.
Sure, keep me posted so I can close this issue. Thanks!
Hello @inlet
I may found the issue.
As the total image size is larger, the memory seems never released in Safari.
On the other hand, in Chrome, JS Heap size works well.
I would appreciate it if you could check my demo.
I don’t see any issues with your demo, it must have to do something with how Safari handles GPU GC.
It might be worth filing an issue in the PIXI repo? Have you tried it with vanilla PIXI?
I don’t see any issues with your demo
It might be because of machine's speck. I'll make it load more image, then you could see the issue.
Have you tried it with vanilla PIXI?
Yes. The first one is with vanilla. When the destroy method is not called, the memory graph looks similar as the one with react-pixi https://codesandbox.io/s/staging-architecture-tl7v0x?file=/src/index.ts
Right so we can confirm the same logic happens with vanilla PIXI.
I’ll close this issue as it’s not related to react-pixi but with PIXI in general
Wait, It can be avoided calling destroy method as a texture changes with vanilla. So I guessed destroy method is not called properly in react-pixi.
Have you tested it out with Sprite that’s getting removed? As you can see in the reconciler tests all unmounted components are getting destroyed properly.
https://github.com/inlet/react-pixi/blob/master/test/reconciler.test.js#L309
In your example you’re updating the texture
prop, please try setting a key
prop that unmounts the old and mounts a new one
@inlet Yesss, it works with key prop!!!!! Thank you so much😭
@inlet FYI: Although it actually works with following code to some extent, it's necessary to set a key prop on Stage component for much heavier images.. (By the way, it didn't work to set a key prop on Sprite component)
<Contaienr key={state}>
<Sprite
...
texture={state}
/>
</Container>
Thanks for the reference 😁
Description
I have this following code, but it causes memory leaking only in Safari, since the Sprite is completely removed. (seems GC not working)
I simulated the same situation with raw PIXI.js. I guess, since the destroy method is running, the memory is not leaking. https://codesandbox.io/s/staging-architecture-tl7v0x?file=/src/index.ts
I'd like to know how to use destroy method with react-pixi, or other way to avoid memory leaking.
Additional info
@inlet/react-pixi
version: ^6.6.5React
version: ^17.0.2ReactDOM
version: ^17.0.2PIXI
version: ^6.2.2