Jump to content

PixiJS6 and the memory question.


ZZZZZZZZZ
 Share

Recommended Posts

I wrote a demo in PixiJS 6.2.2. After I destroyed everything I know, Google Chrome Helper (Renderer)'s memory was still a few hundred megabytes in the activity monitor. Is there anything I haven't destroyed?

The general process is as follows. Open demo in Chrome(40+MB Memory)->Select a 8K image(800+MB Memory)->Run destroyAll(400+MB Memory).

If you have any ideas, please let me know. Thanks.

Operating system: macOS 10.15.6.

Browser: Google Chrome 107.0.5304.110

Demo:

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <title>Document</title>
    <meta name="viewport" content="width=device-width, initial-scale=1.0, maximum-scale=1.0, user-scalable=0"/>
</head>
<body>
    <script src="https://pixijs.download/v6.2.2/pixi.js"></script>
    <script>
let canvasWidth = 1000
let canvasHeight = 800
const app = new PIXI.Application({ width: canvasWidth, height: canvasHeight,  backgroundColor: 0x1099bb});
document.body.appendChild(app.view);

let scaleRatio = 0.1

let originTexture
let mainSprite

function init(o){
    originTexture = o
    mainSprite = new PIXI.Sprite(originTexture)
    mainSprite.x = 0
    mainSprite.y = 0;
    mainSprite.width = originTexture.width * scaleRatio;
    mainSprite.height = originTexture.height * scaleRatio;
    app.stage.addChild(mainSprite)
}
function changeFile(e){
    let src = URL.createObjectURL(e[0])
    let originTextureLoader = PIXI.Texture.fromLoader(src)
    originTextureLoader.then((o)=>{
        URL.revokeObjectURL(src)
        originTexture && originTexture.destroy(true)
        mainSprite && mainSprite.destroy({children:true, texture:true, baseTexture:true})
        originTextureLoader = null
        init(o)
    })
}

function destroyAll() {
    document.body.removeChild(app.view)
    originTexture && originTexture.destroy(true)
    mainSprite && mainSprite.destroy({children:true, texture:true, baseTexture:true})
    PIXI.utils.destroyTextureCache()
    app.renderer.gl.getExtension('WEBGL_lose_context').loseContext()
    app.destroy(true, {children:true, texture:true, baseTexture:true})
}

    </script>
    <div>
        <label>
            Select Image:
            <input type="file" onchange="changeFile(this.files)" />
        </label>
        <button onclick="destroyAll()">destroy</button>
    </div>
</body>
</html>

 

Link to comment
Share on other sites

15 hours ago, ivan.popelyshev said:

Welcome to the chrome. It hates to release memory of the page, it does that rarely. We had to minimize MAX memory on loading for one of apps because of that.

Sorry for my late reply.

I wrote a tool with Vue2 and PixiJS to show pictures. But after I switch it on and off a few times it starts to take up more memory. I destroyed everything I know, but the memory footprint remains high.
 

Link to comment
Share on other sites

https://codepen.io/znw-test/pen/YzvaWKv

I wrote an example. After loading an 8k image, the memory does not change when the Sprite is not added to the Stage. When the Sprite is added to the Stage, the memory starts to get higher. After destroying the Sprite and Texture, the memory footprint is not completely freed. It still takes up 400+MB in the activity monitor, where it was only a few tens of MB.

Is this a bug?

Link to comment
Share on other sites

After a series of tests, it took about six minutes for the new versions of Chrome (v107 and v106) to release the memory footprint. At least that's what it says on the activity monitor. and in older versions of chrome (v87 and v91), memory didn't get released for 12 minutes, which I didn't test for longer.

Maybe it doesn't matter too much?

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...