WebGLRenderLists: Fix the issue that memory for disposed objects is not released

[takahirox]

This PR fixes #12447

Let me know if there's any special reasons that renderItems wasn't cleared in init()

[aardgoose]

Hi,
RenderItems isn't cleared in init() because it acts as a cache of RenderItem objects rather than having repeated allocations for each frame (init is called every frame). This patch will cause excessive heap churn and GC.

[aardgoose]

I came across this issue hence renderLists is exposed by the renderer so you can do:

renderer.renderLists.dispose();

to drop all the references to objects, materials etc after removing a set of objects or finishing with a camera / scene combination. Not an elegant solution but it works, and allows the reductions in per frame heap allocs introduced by renderLists to be maintained.

[takahirox]

You mean, array.length = 0 allocates new memory?

And I don't think renderer.renderLists.dispose(); is a good idea. I don't want users to be aware of renderer.renderLists for object disposal.

[takahirox]

Ah, you meant allocating new memory here if we clear renderItems, don't you.

https://github.com/takahirox/three.js/blob/871abf5cd090a67c5373bbdbf67f4dd7532d77ba/src/renderers/webgl/WebGLRenderLists.js#L73-L82

OK, I need to update not to allocate new memory each frame...

[takahirox]

Updated

[aardgoose]

Correct, that's the allocation the render lists caches.

Don't know what the performance hit is of clearing all the references, in most cases, with an unchanged number of render items between frames you could probably avoid most of this clearing by using renderListIndex as a high water mark from the previous frame and clear from renderListIndex to renderList.length - 1 : That is, the RenderItems that haven't been overwritten in the previous frame.

I think this would in the common case avoid most of the overhead?

The renderLists.dispose() function is the only answer in some cases where a camera/scene combination won't be reused, but yes it is a very blunt object and a bit ugly except in special cases ( I required it after a rtt pass.

[takahirox]

Updated.

I think having WebGLRenderList.finish() again like r86 and clearing references in it would be more straightforward.

@mrdoob Let me know if you don't wanna have WebGLRenderList.finish() again.

[Mugen87]

We should merge this PR or a similar solution. There are scenarios where WebGLRenderList effectively avoids garbage collection, see https://jsfiddle.net/v6bbxxa1/

Although 90 of the 100 objects are removed, the internal renderItems array of WebGLRenderList still has 100 entries with references to obsolete geometries. Something like WebGLRenderList.finish() would free this stuff.

[mrdoob]

This is how the code used to be before. I changed it because, depending on the scene, it would be creating and deleting objects all the time.

Would using WeakMaps help here?

[aardgoose]

@mrdoob
You sadly couldn't replace the list with a WeakMap. You can't iterate them which is the price of weak references + keys must be objects, so the string 'hash' wouldn't work.

[anzorb]

Our application suffers from this in production and we are seeing GPU process crashes due to a memory leak. Running renderer.renderLists.dispose() makes the profile look clean again. How far is this PR from being complete/released and what do you recommend doing in the meantime? When is a good time to run renderer.renderLists.dispose()? Thanks!

EDIT: looks like updating to r91 has resolved this issue. I'll continue to monitor.
EDIT: looks like there were still Arrays left behind, that are referencing Geometries that were disposed. Calling renderer.renderLists.dispose() after bulk removal of meshes looks to be the solution for now.

[aardgoose]

in WebGLRenderList.sort() you could do

renderItems.length = transparent.length + opaque.length; to limit the cache to the current amount used.

Its the separation of cache between (scene, camera ) pairs that gives the bulk of the benefit here I think rather than caching withing a (scene, camera) pair, and would handle this case without setting arbitrary limits.

[sgaoae]

What about clear all of the renderItems after each render?

function clearRenderItem (renderItem) {
    renderItem.id = undefined;
    renderItem.object = undefined;
    renderItem.geometry = undefined;
    renderItem.material = undefined;
    renderItem.program = undefined;
    renderItem.groupOrder = undefined;
    renderItem.renderOrder = undefined;
    renderItem.z = undefined;
    renderItem.group = undefined;
}
renderList = renderer.renderLists.get(scene, camera)
for (let i = 0; i < renderList.renderItems.length; ++i) {
    clearRenderItem(renderList.renderItems[i])
}
// or clear opaque and transparent array instead?
for (let i = 0; i < renderList.opaque.length; ++i) {
    clearRenderItem(renderList.opaque[i])
}
for (let i = 0; i < renderList.transparent.length; ++i) {
    clearRenderItem(renderList.transparent[i])
}

Sorry, never mind. I didn't check all of the commits. This pr will solve the problem.

[Mugen87]

@sgaoae I think the PR implemented this approach but in a slightly different way. Clearing the internal renderItems is sufficient since the same items of this array are in the opaque and transparent render lists.

[aardgoose]

@sgaoae if you have a case where the object count in a scene reduces significantly as you propose you can always use the brute force approach which removes all the references, if this PR is not adopted.

renderer.renderLists.dispose();

[endel]

Just stumbled upon this issue by searching the web for "renderItems memory leak", as my app rebuilds the scene quite often, the suggestion @aardgoose made (#12464 (comment)) seems perfect for me so far.

[viazmin]

I'm using a lot of large BufferGeometries and manually removing all the attributes from them before disposing, frees up most of the memory (r104).

for (const key in geometry.attributes) {
    geometry.removeAttribute(key);
}
geometry.setIndex([]);
geometry.dispose();

[Mugen87]

Closing in favor of #18411.