alt Hacker NewsWebGPU is far from cheap and has to do a substantial amount of extra work to translate to the underlying API in a safe manner. It's not 1:1 with Vulkan and diverges in a few places. WebGPU uses automatic synchronization and must spend a decent amount of CPU time resolving barriers.
You can't just ship a WebGPU implementation in the driver because the last-mile of getting the <canvas> on screen is handled by the browser in entirely browser specific ways. You'd require very tight coordination between the driver and browsers, and you still wouldn't be saving much because the overhead you get from WebGPU isn't because of API translation, rather it's the cost to make the API safe to expose in a browser.
We already do this by exposing the canvas surface with a semaphore lock. The browser can flip the surface to the canvas (or your app can flip it onto a window surface).
It’s just a HINSTANCE pointer.
You’re right about the waiting, but that’s entirely app driven. Browsers don’t want to render at 144fps but rather wait until drawing has occurred in order to update the view.
wgpu, dawn, already support drawing to arbitrary surfaces (not just a canvas but any window surface).