I learned only by overhearing discussions that Surface::get_current_texture() blocks if the GPU hasn't finished previously presented work. Further experiment determined that this is true on native, but on the WebGL backend (on Chrome), instead it seems like submit() is the call that takes extra time. (I have not tested WebGPU.)

It would be useful to document which of these calls may block, when, so that applications can design around this. In my case, I primarily wanted to collect performance measurements, so it's useful to know which things are especially worth measuring, but additionally it may be useful to order steps such that as much CPU work is done as possible before entering get_current_texture(), to maximize concurrency between the CPU and GPU.

Additionally, it would be nice to have non-blocking alternatives, so that applications may spend time on other work rather than purely waiting for the GPU, without necessarily having to introduce multithreading at that point. (For example, consider the classic problem where something flashy happens on screen and produces Way Too Many Particle Effects for the available fillrate; if the simulation of those effects can proceed asynchronously, then the system will recover faster since it will have progressed past those effects sooner.)