UnswapchainV2.md

partial interface GPUDevice {
    GPUSurface createSurface(GPUSurfaceDescriptor descriptor);
};

interface GPUSurface : GPUTexture {
    ImageBitmap transferToImageBitmap();
};

dictionary GPUSurfaceDescriptor : GPUObjectDescriptorBase {
    ImageBitmapRenderingContext context;
    GPUExtent3D size;
    required GPUTextureFormat format;
    GPUTextureUsageFlags usage = 0x10; // GPUTextureUsage.OUTPUT_ATTACHMENT
};

Either context or size is required (not both). If context is specified, then its canvas's size is used. The surface may be optimized for display to that canvas.

Note: For example, this may mean the surface points at an image in an IDXGISwapChain created for this canvas. However, such optimizations are not observable. An ImageBitmap created from a GPUSurface can be used just like any other ImageBitmap, regardless of the context specified. The ImageBitmapRenderingContext can still receive any ImageBitmap.

---

Internally, any necessary copies-on-write or moves-on-write will occur.

For example, on D3D12/DXGI, with a canvas that has had control transferred to an OffscreenCanvas, and an ImageBitmapRenderingContext ibrc created from it:

• A GPUSurface s could be allocated inside a swap chain buffer.
• An ImageBitmap ib created from s would still point at the same allocation.

If this is done, then:

• Transferring ib into ibrc would cause a swap chain present.
• Transferring another unrelated ImageBitmap, ib2, into ibrc would cause ib to be moved into a new backing store and ib2 to be copied into the swap chain and presented.
• Consuming ib in another way would cause the swap chain buffer to be freed for reuse by another surface.
• Using ib in a non-consuming way would just read-back from its allocation in the swap chain buffer.
• Creating another GPUSurface s2 would do a normal allocation (not inside the swap chain buffer, because that space is already used).

Any deoptimization cases could issue warnings.

Also note that any canvas which is synchronized with DOM rendering (i.e. any non-transferred-to-offscreen canvas) cannot be presented via IDXGISwapChain, because IDXGISwapChain::Present does not guarantee which frame the result will appear on.

Possible documentation bugs

[1] refers to the "swap chain's zero-index buffer", which seems to be wrong with D3D12 since it doesn't renumber the swap chain buffers on present.

[3] says that only FLIP_SEQUENTIAL can be used, but we are using DISCARD already in Dawn.

• What happens when the canvas element resizes? Do you need to say "its canvas's size at creation time is used"? What is the process to update the size?

Yes, I should say "at creation time". Other than that I think it's pretty straightforward - since you create a new surface every frame (not sure if that was clear above), you just end up with an ImageBitmap of the old canvas size and what happens is exactly the same as what usually happens when you present an improperly sized ImageBitmap to an ImageBitmapRenderingContext.

Sure, I meant... what if there's a resize and the developer WANTS to use the new size? Does it create a new GPUDevice? You need a way to do this resize that is not super complicated.