The way I think we should go about this is having a lightweight "client" implementation of WebGPU that encodes commands into a ringbuffer, that can be read by the host and forwarded (after some checks / handles translations) to the native WebGPU implementation.
WebGPU objects on the wasm side should be treated as handles, and translated to webgpu pointers on the native side through a separate handle table (this way the wasm side can't touch native webgpu objects used by the runtime, eg by the vector graphics backend).
The way I think we should go about this is having a lightweight "client" implementation of WebGPU that encodes commands into a ringbuffer, that can be read by the host and forwarded (after some checks / handles translations) to the native WebGPU implementation. WebGPU objects on the wasm side should be treated as handles, and translated to webgpu pointers on the native side through a separate handle table (this way the wasm side can't touch native webgpu objects used by the runtime, eg by the vector graphics backend).