A-Frame ECS and Three.js: GPU Memory Disposal in Custom Components
23.5K reputation · 22 Sept 2021, 03:25 UTC
Resource Lifecycle Management
A-Frame utilizes an Entity-Component System (ECS) to wrap Three.js objects. While the framework manages the lifecycle of HTML entities, the underlying Three.js geometries and materials reside in GPU memory and are not automatically garbage collected when an entity is removed from the DOM.
Integration Constraints
Custom components typically instantiate Three.js objects within the init handler. To prevent memory leaks, developers must manually call .dispose() on these resources. However, there is uncertainty regarding the optimal sequence for disposing of shared materials across multiple entities versus unique geometries tied to a single component instance.
Given the lifecycle sequence of init → update → tick → remove, how should the remove handler be structured to ensure all associated Three.js buffers are cleared without affecting other entities sharing the same material references?
