Use WebWorker to handle WebTransport connection about ambient

[pierd]

I did some smaller isolated experiments first to iterate quicker on a few ideas, if anyone is interested they are here: https://github.com/pierd/webtransport-lag-investigation. Long story short transferring a single stream either to worker or from worker doesn't really help with the lag bug. To be mostly unaffected by it the webtransport has to be created in the worker and it has to do the polling.

[pierd]

With that I prepared a POC implementation in Ambient (quick and dirty: main...kuba/webworker). I haven't updated the tooling so it's impossible to make a proper internal deployment of it yet but I made a build by hand and uploaded it. For comparison I also made a regular build with frame dropping and another one with frame dropping disabled. You can check them out here:

• regular frame dropping: https://artifacts.ambient.run/kuba-test/frame-dropping2.html
• no frame dropping: https://artifacts.ambient.run/kuba-test/no-frame-dropping.html
• experimental webworker (also without frame dropping): https://artifacts.ambient.run/kuba-test/webworker.html

[pierd]

Previously, with the regular input lag bug, when frame time goes to high (values higher than the refresh rate expected by the browser) the latency goes up out of control and it's measurable in the write call of WebTransport's outgoing datagrams stream.

The POC still has a lag issue but it's different. Now the network code doesn't have any weird delays, the lag comes from slow message passing from the worker to the main app/thread (as measured from postMessage call on the worker to onmessage being called in the main app). It can easily go up to 300 ms. Note that when animation frame is not delayed, the message passing is consistently fast (0-1 ms).

I doubt that the delay comes from serialization/allocation/memory copy time because:

• completely not existent when animation frame callback is processed in time,
• it also affects tiny messages (an array of 2 elements: 4 character string and an f64) and incoming data rate is <1kB/s - that's not much memory to handle even if it's done poorly.

[pierd]

Added a WASM client version to the minimal experiment (pierd/webtransport-lag-investigation@eb0123c) but I still can't reproduce the postMessage-onmessage lag seen on Ambient. There must be something more happening.

[pierd]

On its own this change doesn't address CPU starvation that is the main reason of our input lag. As such it should be revised as a part of bigger architectural change.

Longer story

Currently experienced lag is caused by networking starvation caused by busy main thread. The network data is handled by the browser but not passed for processing as the thread is busy within requestAnimationFrame callback. Our temporary solution uses frame dropping when long frame processing time is discovered.

Using webworker to process networking doesn't fully solve the issue. The data is received in a timely manner but it has to be passed to the main thread for processing. Since the main thread is busy, the webworker's onmessage callback is being delayed - a new source of input lag.

To fix input lag properly we need an architectural change. Rendering should be processed in a separate thread that is independent from simulation and networking. Without it, busy rendering will always starve other tasks.