The non-async version of createRenderPipeline may cause rendering to block on shader compilation. It makes sense that WebGPU rendering would block, but it will also end up blocking rendering of all DOM updates, other canvases, and requestAnimationFrame at least, possibly more.

Perhaps we could reduce the amount of blocking by specifying that the use of non-async createRenderPipeline may cause the synchronization of WebGPU rendering and DOM updates to be temporarily broken, so DOM updates can continue to be rendered as shaders compile.

We can keep calling requestAnimationFrame to update other JS-driven animation, though we would need some kind of backpressure mechanism to keep applications from queueing dozens of frames while rendering is blocked. For example, we could make GPUSwapChain.getCurrentTexture fallible.