Run bevy systems in wasm even when the tab is not focused

[cBournhonesque]

What problem does this solve or what need does it fill?

It seems like if the user switches to a different tab, the bevy app will basically freeze and stop getting updated.

This seems to be because running the schedule in wasm is tied to requestAnimationFrame (https://developer.mozilla.org/en-US/docs/Web/API/window/requestAnimationFrame) calls which are made by winit in the winit_runner.

A potential solution would be:

• if the tab is focused, keep the current scheduling logic
• if the tab is not focused, update the schedule at fixed intervals (for example 60Hz(

[Nul-led]

To add to this, while unfocused, bevy could run in headless mode (meaning no user io / rendering and input need to be collected).

Implementation wise this could make use of various web-apis such as setTimeout, setInterval, requestIdleCallback, queueMicrotask and Web Workers.

[jabuwu]

For posterity...

The comment in winit is a bit misleading. It says the strategy "is not affected by browser throttling", but this isn't always true. This seems to be the culprit: https://developer.mozilla.org/en-US/docs/Web/API/Scheduler/postTask#delaying_tasks
If a delay is set, the task will get scheduled with setTimeout, and we're back to throttle town. ControlFlow::WaitUntil will set a delay.
Using ControlFlow::Poll will cause the background tabs to stop throttling. I was able to check this by changing the value here to use poll and using bevy::winit::UpdateMode::Continuous:

bevy/crates/bevy_winit/src/lib.rs

Line 494 in f91fd32

event_loop.set_control_flow(ControlFlow::Wait);

Interestingly, in my testing with Poll, requestIdleCallback works pretty well but eventually stops updating in the background tab. Scheduler.postTask stalls out really quickly when delay > 0 and stops updating. setTimeout doesn't throttle ever, like I expect it to. Scheduler.postTask with delay = 0 never stalls out (but maybe starves the browser? not sure how rendering/vsync fits into all this)

https://discord.com/channels/691052431525675048/750833140746158140/1240217724354039858

It seems this is achievable right now by using ControlFlow::Poll and PollStrategy::Scheduler. Not sure the adverse effects of this change. Warrants more investigation. 😁

[jabuwu]

For this specific problem, I think web workers might be best. Spawning a web worker and having it run the setTimeout instead results in much faster and more accurate intervals, and web workers don't get throttled the same way browser tabs do. A postMessage from a web worker to a browser tabs wakes it immediately. The scheduler solution might be okay, but browser support isn't great

Unfortunately, at this point, winit doesn't support that strategy. It could probably be added as one.

Although, the issue that originally implemented scheduler with setTimeout fallback mentions a trick that might explain the results I was seeing with setTimeout: rust-windowing/winit#3044

Not sure I understand what that trick is. 🙂 Maybe it's also related to the postMessage it uses.

Also, regarding vsync and requestAnimationFrame: rust-windowing/winit#2880

[cBournhonesque]

https://github.com/Nul-led/bevy_web_keepalive/tree/main fixes this issue for now

[daxpedda]

The comment in winit is a bit misleading. It says the strategy "is not affected by browser throttling", but this isn't always true. This seems to be the culprit: https://developer.mozilla.org/en-US/docs/Web/API/Scheduler/postTask#delaying_tasks
If a delay is set, the task will get scheduled with setTimeout, and we're back to throttle town. ControlFlow::WaitUntil will set a delay.

The comment in Winit is on PollStrategy, which only affects ControlFlow::Poll and doesn't affect ControlFlow::WaitUntil, so it should be correct that it never throttles.

Winit uses Scheduler.postTask() internally for ControlFlow::WaitUntil (unless its not available, in which case it falls back to setTimeout()), so this will be subject to browser throttling because it uses delay.

For this specific problem, I think web workers might be best. Spawning a web worker and having it run the setTimeout instead results in much faster and more accurate intervals, and web workers don't get throttled the same way browser tabs do. A postMessage from a web worker to a browser tabs wakes it immediately. The scheduler solution might be okay, but browser support isn't great

Unfortunately, at this point, winit doesn't support that strategy. It could probably be added as one.

I think using Web Workers for ControlFlow::WaitUntil to prevent throttling in Winit isn't a particularly good idea because Winit shouldn't try to prevent throttling by default. But adding something like WaitUntilStrategy to let users opt-in to prevent throttling would be a viable option. I will open an issue in Winit for this (EDIT: see rust-windowing/winit#3738).

This would all be unrelated to Scheduler, so I'm not sure whats meant with that here.

Although, the issue that originally implemented scheduler with setTimeout fallback mentions a trick that might explain the results I was seeing with setTimeout: rust-windowing/winit#3044

Not sure I understand what that trick is. 🙂 Maybe it's also related to the postMessage it uses.

Winit doesn't use setTimeout() unless its a polyfill for Scheduler.postTask() which doesn't throttle the same way setTimeout() does. So to align the behavior of setTimeout() to Scheduler.postTask() we avoid the inherent throttling of using setTimeout() recursively by passing it through MessagePort.postMessage().

But both the setTimeout() trick and Scheduler.postTask() with a delay will throttle when the tab is unfocused on Chromium, so this doesn't help us here in any way.

Also, regarding vsync and requestAnimationFrame: rust-windowing/winit#2880

Keep in mind that rust-windowing/winit#2880 was reverted in rust-windowing/winit#3044 and RedrawRequested is a VSync source now in Winit since rust-windowing/winit#2896 (although calling it VSync source is contentious).

[jabuwu]

This would all be unrelated to Scheduler, so I'm not sure whats meant with that here.

I was only trying to say that, when the comment was written, the only option to avoid throttling (without a winit change) was to use scheduler and ControlFlow::Poll.

[daxpedda]

This would all be unrelated to Scheduler, so I'm not sure whats meant with that here.

I was only trying to say that, when the comment was written, the only option to avoid throttling (without a winit change) was to use scheduler and ControlFlow::Poll.

To clarify: the PollStrategy::Scheduler should never throttle, regardless of whether the Scheduler API or the setTimeout() fallback is used.

I think using Web Workers for ControlFlow::WaitUntil to prevent throttling in Winit isn't a particularly good idea because Winit shouldn't try to prevent throttling by default. But adding something like WaitUntilStrategy to let users opt-in to prevent throttling would be a viable option. I will open an issue in Winit for this (EDIT: see rust-windowing/winit#3738).

This is now implemented in rust-windowing/winit#3739 and should be released in Winit v0.30.3 soon.