Immediate disposal or a shared resource cache for long-running three.js scenes?

Answer

For a dashboard that adds and removes thousands of meshes over hours, a reference‑counted cache keyed by asset identity is the recommended strategy. It guarantees that GPU resources are freed only when the last object that uses them is removed, while avoiding repeated uploads of identical geometry, material or texture instances. Disposal should be performed after the current frame has finished rendering (e.g., immediately after renderer.render() or inside a requestAnimationFrame callback).

Why a cache beats immediate disposal

• Immediate disposal guarantees no VRAM leak but forces a full GPU upload every time an identical asset is needed again, which can stall the main thread and increase frame times.
• A shared cache keeps a single WebGL buffer or texture in VRAM. When no Mesh references it, the reference count drops to zero and dispose() is called, reclaiming the memory.
• Reference counting prevents accidental disposal of a resource still in use elsewhere and automatically cleans up stale entries when the last user leaves.

When to dispose safely

WebGL forbids deleting a buffer or texture that is currently bound. The safest moment is after the render call has returned, when the driver has unbound all resources. In practice you can schedule disposal in the same animation loop that calls renderer.render():

function animate() {
  requestAnimationFrame(animate);
  renderer.render(scene, camera);
  // Dispose any objects queued for removal
  disposePending();
}

Typical cache implementation

• Key the cache by a stable asset identifier (e.g., a string hash of the geometry’s vertex data, material’s shader code, or a texture URL).
• Store an object containing the actual Three.js resource and a refCount field.
• When a Mesh is created, increment refCount for each resource it uses. When the Mesh is removed, decrement the counts and call dispose() only when a count reaches zero.
• Keep a separate queue for resources that have just hit zero and dispose them after the frame.

Verification checklist

1. Run a create/remove loop with ~1,000 meshes using identical geometry/material/texture.
2. Use renderer.info.memory before and after each iteration to confirm that geometry, material, and texture counts stay stable.
3. Monitor VRAM via browser devtools or an external profiler; a reference‑counted cache should not show a steady increase in VRAM usage.
4. Check for WebGL errors after each frame; the absence of gl.INVALID_OPERATION indicates safe disposal timing.

Missing diagnostic detail

Could you share the typical reuse frequency of assets in your dashboard? Knowing whether most assets are reused within a few frames or only after long periods would help fine‑tune the cache eviction policy (e.g., LRU vs reference counting).