Imported by name, unlike CacheableGeometry and CacheableTexture, which
are derived from the render item that carries them. The reason is that the
two are genuinely different situations rather than an inconsistency: a
geometry or a texture reaches the backend through a material, as a
structural read contract that more than one class can satisfy, whereas a
render target reaches it as the fourth argument of Renderer.render, typed
as this one class — @fourjs/render is already a dependency (plan §3.1), the
class carries private state and so cannot be satisfied structurally anyway,
and naming it is what lets render-webgl's tests drive this cache with the
real thing (decision, R-4).
The render-target type this cache stores.
Imported by name, unlike
CacheableGeometryandCacheableTexture, which are derived from the render item that carries them. The reason is that the two are genuinely different situations rather than an inconsistency: a geometry or a texture reaches the backend through a material, as a structural read contract that more than one class can satisfy, whereas a render target reaches it as the fourth argument ofRenderer.render, typed as this one class —@fourjs/renderis already a dependency (plan §3.1), the class carries private state and so cannot be satisfied structurally anyway, and naming it is what letsrender-webgl's tests drive this cache with the real thing (decision, R-4).