WACS.WASI.GFX.DependencyInjection 0.2.1-preview

WACS.WASI.GFX.DependencyInjection

Microsoft.Extensions.DependencyInjection extensions for WACS.WASI.GFX. Symmetric with WACS.WASI.NN.DependencyInjection and WACS.WASI.Preview2.DependencyInjection.

Usage

using Wacs.WASI.Preview2.DependencyInjection;
using Wacs.WASI.GFX.DependencyInjection;
using Wacs.WASI.GFX.Silk;

services
 .AddWasiPreview2()
 .AddWasiGfx(b => b.WithBackend(new SilkGfxBackend()))
 .AddWasiPreview2GfxBundle(); // composite for the
 // single hostBundle slot

The composite WasiPreview2GfxBundle forwards property lookups to either the Preview2 sub-bundle or the wasi-gfx sub-bundle. Components importing both wasi:cli/* and any wasi-gfx package resolve through one bundle slot.

What's in the box

WasiGfxBundle carries the configuration + backend. WasiPreview2GfxBundle is the composite the transpiler's HostPackageResolver direct-links against when both Preview2 and wasi-gfx are loaded.

Per-resource impl classes (Context, AbstractBuffer, Surface, Device, Buffer) follow the SourceGen-resource convention — parameterless ctor + Create(). Context / Surface / Device prefer a bundle-taking ctor (the v1 phase-1g shape) and source the backend from bundle.Configuration.Backend. The [static]buffer.from- graphics-buffer factory and any parameterless-ctor fallback read from the AsyncLocal-scoped WasiGfxCurrent. They live in this package and the resolver discovers them via TryFindResourceImpl.

Both engines run wasi-gfx components end-to-end:

# Interpreter component path:
wacs run --wasi-gfx --windowed my.component.wasm

# Transpiler direct-link path:
wacs run --wasip2 --wasi-gfx --windowed my.component.wasm

AddWasiGfx + AddWasiPreview2GfxBundle register everything via Microsoft.Extensions.DependencyInjection. The CLI auto-wires both at startup via the WasiPreview2RuntimeScope.ReflectivelyAddWasiGfx hook in Preview2's DI scope.