Documentation
    Preparing search index...

    Class RendererRegistry

    The backends an application has opted into, and the §62 selection rule over them (R-2).

    Applications normally use the shared registry through registerRenderer and resolveRenderer and never name this class. Construct one directly to keep a selection scope to itself — a test that must not see another test's registrations, or a host embedding two independent engines:

    const registry = new RendererRegistry();
    registerWebglRenderer(registry);
    const renderer = await resolveRenderer("auto", { canvas }, registry);
    Index
    • get backends(): RendererBackend[]

      The registered backends, in registration order.

      Returns RendererBackend[]

    • get size(): number

      Number of registered backends.

      Returns number

    • Whether backend is registered.

      Parameters

      Returns boolean

    • Adds registration. Returns this so registrations chain.

      Parameters

      Returns this

      FourError RENDERER_INITIALIZATION_FAILED if that backend is already registered. A silent overwrite would make which renderer "auto" builds depend on module evaluation order, which is the class of bug §33 exists to prevent. Use a second registry, or RendererRegistry.unregister.

    • Builds and initializes the renderer selection names (§62).

      An explicit backend fails fast. §62 requires it: renderer: "webgpu" on a machine without WebGPU must say so, not quietly hand back WebGL 2 and leave an application wondering why its compute pass never ran. So an unregistered name, an unsupported environment, and a rejected initialize all reject here, unchanged and uncaught.

      "auto" walks AUTO_RENDERER_ORDER and takes the first backend that is registered, answers RendererRegistration.isSupported, and initializes. Every backend it passes over is reported through RendererResolveOptions.onFallback — §62's diagnostics event — and a backend whose initialize rejected is disposed before the walk continues, so a half-acquired context is not left behind. When nothing works the rejection names every backend that was tried and why each one was not used; when nothing is registered it says that instead, which is the mistake this API is most likely to produce.

      The renderer comes back initialized. That is forced by §62 — falling back on initialization failure is only possible if the registry is the one calling initialize — and callers must not call it again (backends treat a second call as an error).

      Parameters

      Returns Promise<Renderer>

    • Removes backend's registration; true if there was one.

      Parameters

      Returns boolean