Material disposal behavior across Three.js renderer program cache boundaries

Three.js documents explicit .dispose() calls as the required mechanism for releasing GPU memory held by geometries, materials, textures, and render targets, because JavaScript garbage collection does not automatically free WebGL buffers. In long-running applications, developers depend on this contract to prevent leaks when objects leave the scene graph.

The uncertainty arises at the boundary between material disposal and the WebGLRenderer's internal program cache. While material.dispose() removes the material's own GPU resources, the renderer may retain the compiled WebGLProgram if another material shares compatible shader parameters or renderer state. This makes it difficult to determine when a shader program becomes eligible for driver-side deallocation, especially since renderer.info.memory counters track geometries and textures but not programs directly, and may lag behind actual reclamation.

Version-sensitive cache eviction semantics and browser WebGL implementation differences further complicate the lifecycle. Applications that dynamically generate materials need a predictable boundary between JavaScript-side disposal and GPU-side program release.

Under what conditions does the Three.js renderer evict a cached WebGLProgram after all materials using it have been disposed? Does renderer.info expose a reliable counter for live shader programs across recent releases, or must developers inspect internal state? What is the documented compatibility boundary between calling material.dispose() and expecting the underlying shader program to be freed without a context loss?