Pixi.js: Framebuffer does not release depth buffer when destroyed, causing GPU memory leak

[Vanilagy]

I noticed that if you (manually) add a depth texture to a Framebuffer, that texture does NOT get cleaned up by calling destroy() on the framebuffer, although arguably, it should, since it belongs to the buffer.

Expected Behavior

The depth texture gets destroyed alongside all the color textures.

Current Behavior

The color textures get destroyed while the depth texture doesn't, causing a memory leak.

Possible Solution

Add destruction of the depth texture when destroying the framebuffer.

Steps to Reproduce

I created a commented Fiddle that can help with reproducing the problem:
https://jsfiddle.net/ncj95301/

Click "Start", then check your VRAM usage, it should go up quite quickly.

Environment

• pixi.js version: _5.2.1_
• Browser & Version: _Chrome 80.0.3987.163_
• OS & Version: _Windows 10.0.18362 Build 18362_
• Running Example: _https://jsfiddle.net/ncj95301/_

[ivanpopelyshev]

Ha! First user of DepthTexture that I see ! I really dont know the demo it was used before.. OK then, time to find that bug.

Yes, it blongs to the framebuffer: https://github.com/pixijs/pixi.js/blob/dev/packages/core/src/framebuffer/FramebufferSystem.ts#L517 . Yes, as you said, in webgl its separate, but in PixiJS it appears only with framebuffer, its fine to dispose it there.

[Vanilagy]

Haha yeah man, people who DepthTexture might be rare, but we exist! I'm actually surprised they're rarely used, since depth buffers have always been an important part of computer graphics.

[SukantPal]

@bigtimebuddy This is actually a structural problem with Pixi. The depth-texture is not owned by the framebuffer; the color textures aren't freed either. If you call RenderTexture#destroy, it destroys itself (which happens to be the only color texture) and disposes the framebuffer.

[SukantPal]

@bigtimebuddy I suggest that RenderTexture#destroy actually does the work of destroying the depth texture. See my proposed fix: https://github.com/pixijs/pixi.js/pull/6561

[SukantPal]

@Vanilagy Please verify the fix: https://jsfiddle.net/ShukantPal/6jqsfa7v/

[Vanilagy]

Verified, the leak is gone.