Using `windowing-systems-graphics-apis` worlds instead of graphics-context

[MendyBerger]

In a recent conversation I had with @lukewagner he proposed a different solution to the problem of connecting windowing-systems with graphics-apis.
His idea was to have a special world for each connection type, e.g. a surface-webgpu world, and a surface-frame-buffer world.
At the time I dismissed the idea because it would mean we'd need windowing-system types * graphics-api types worlds, which could grow quickly.

However, while I'm still concerned about the explosion of worlds, I think this approach would provide two advantages (besides just being simpler for developers - which Luke mentioned)

1. It would allow us to have specific options/parameters for each connection type. E.g. we could put a GPUCanvasContext there (perhaps with a different name), which would be closer to the WebGPU spec.
2. It won't require us to lock in decisions in graphics-context (e.g. managed swapchain, or providing a present method).

Given all these advantages, I'm starting to think that it's a better approach after all.

@seanisom thoughts?

[seanisom]

This makes sense to me. Although it may be an explosion of worlds, it reduces the number of "base" concepts/proposals by getting rid of wasi-graphics-context. These same implementations would need to exist, whether they are in their own world or not. An implementation could still not support a connection by just not exporting the specific world. It makes sense that different implementations could need different state (similar to how additional state is passed at context creation in the windowing system in OpenGL, but is opaque to the OpenGL implementation itself.

I'm good with this.

[lukewagner]

Thanks for all the discussion and consideration!

One additional tool we should have in the future to mitigate world explosion is optional imports. (We've been meaning to add optional imports since WASI Preview 1 and once we ship Preview 3, it's probably time to finally add it.) With optional imports, I think you could write something like:

package my:windowing-system;
world app {
  import types;
  import optional webgpu;
  import optional canvas2d;
  ...
}
interface types {
  resource window { ... }
  ...
}
interface webgpu {
  use types.{window};
  use wasi:webgpu/types.{gpu-canvas-context};
  resource connection {
    create: static func(cx: borrow<gpu-canvas-context>, w: borrow<window>) -> result<connection>;
    ...
  }
}
interface canvas2d {
  ... likewise
}

So there'd be 1 world per windowing system (which seems like what you'd expect). Even without optional imports, I expect one could achieve the same effect by non-optionally importing webgpu/canvas2d and having all the constructor functions return runtime errors if webgpu/canvas2d wasn't supported.