Comments (7)
https://github.com/Nul-led/bevy_web_keepalive/tree/main fixes this issue for now
from bevy.
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 adelay
is set, the task will get scheduled withsetTimeout
, and we're back to throttle town.ControlFlow::WaitUntil
will set adelay
.
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. ApostMessage
from a web worker to a browser tabs wakes it immediately. The scheduler solution might be okay, but browser support isn't greatUnfortunately, 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#3044Not 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).
from bevy.
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
.
from bevy.
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 likeWaitUntilStrategy
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.
from bevy.
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.
from bevy.
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 adelay
is set, the task will get scheduled withsetTimeout
, and we're back to throttle town.ControlFlow::WaitUntil
will set adelay
.
UsingControlFlow::Poll
will cause the background tabs to stop throttling. I was able to check this by changing the value here to use poll and usingbevy::winit::UpdateMode::Continuous
:
bevy/crates/bevy_winit/src/lib.rs
Line 494 in f91fd32
Interestingly, in my testing with
Poll
,requestIdleCallback
works pretty well but eventually stops updating in the background tab.Scheduler.postTask
stalls out really quickly whendelay > 0
and stops updating.setTimeout
doesn't throttle ever, like I expect it to.Scheduler.postTask
withdelay = 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. 😁
from bevy.
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
from bevy.
Related Issues (20)
- `insert_if_new` does not have a non-panicking variant
- per edge border colors HOT 3
- Add a method to Trigger to get a list of the triggered component IDs
- Add a Command to trigger observers with statically known components
- Not possible to render to a texture without a window HOT 1
- 2D Motion Blur
- Enable `unused_qualifications` lint at the workspace level
- BorderlessFullscreen does not cover the menu bar on macOS HOT 2
- Stop special-casing UI leaf-node borders
- Regression involving padding HOT 1
- Follow-up: Make `bevy_math`'s `ops` public (and document the methods)
- Genenerate doc comments from Required Components HOT 3
- Expose Required Component Info Through Reflection
- Consider Enabling `apply_clones` Lint
- Retrying a trigger
- Inputs clash in 3d_gizmos example HOT 1
- Use ThinColumn for both resources and sparse sets
- Make toggling visibility easier HOT 6
- Add support for auxiliary/fragment nodes in ui layouts and scenes HOT 5
- Add `filter_map_unchanged()` to `Mut<T>`
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from bevy.