5 ms·

Does anyone know how to correctly deal with these paused tabs for computing incremental games with timer based events? It claims that it still ticks timers onc

Does anyone know how to correctly deal with these paused tabs for computing incremental games with timer based events? It claims that it still ticks timers once a minute for background tabs, but I can measure that it ticks exactly zero times for background tabs (and from now on also for foreground tabs that are occluded...), and in addition may also lie in results of Date.now(). So what does the article even mean by "once per minute"? If I put a tab in background, it immediately stops any tick, if I bring the tab back in the foreground 24 real life hours later, it'll have been 24 real life hours since its last update, not one minute, as I can see by printing events in the console. That makes it difficult to correctly update how much resources were produced in the game, etc....

fabian2k 6y ago
You can never rely on the timers firing exactly as you request, so you always have to take the delta since the last timer and use that in your calculations. This is a very basic issues with doing stuff on a timer, and not that hard to do properly. It shouldn't make a difference if your timer is called once per second, once per minute or once in 10 hours in the background, you always calculate based on the delta to the last time your timer fired.
- Aardwolf 6y ago
  It can be an issue if the game can do complex actions at any time: if you then need to do all of it in one gigantic update after e.g. 24 hours of being in the background, it may take too long to compute that one long tick. Depending on what type of game it is. If it just has to compute "so many resources per second produced" it's easy of course and you can use the delta between last tick (if Date.now() works correctly), but if the game can auto-build various things with complex interactions, it can become computationally complex if it has to do all at once.
  - intellix 6y ago
    It sounds like the tab throttling is working as intended then. If I've moved from your game and haven't looked at it then why shouldn't all of that extra computation happen until the next time I'm interested?
    - bobbylarrybobby 6y ago
      For idle games, much of the point is investing in auto-building, then coming back to the game when your investment has borne fruit. For this to work, it has to be able to run in the background.
      - CyberDildonics 6y ago
        There is a big difference between throttling and not running. Still, it is probably much better to sync with the server than run something at full blast to increment some counters.
      - iofiiiiiiiii 6y ago
        Sounds like it's time for the game authors to provide some servers with the compute resources to do this background processing.
  - chhamilton 6y ago
    (Chromium dev here.) Doing the work in one giant update is actually better from a power consumption / battery point-of-view, because the CPU cost is fixed but there are fewer wakeups overall. Note that the new throttling logic means you get woken-up once per minute; we're not talking about preventing your page from doing work for a 24 hour period. For full details of how the throttling works, see here: https://www.chromestatus.com/feature/4718288976216064 https://www.chromestatus.com/feature/4718288976216064
- nextaccountic 6y ago
  But if it lies about Date.now() this isn't possible..
  - CyberDildonics 6y ago
    That would be broken and isn't what is being talked about here. There is no reason scheduling as a low priority would mean you need to lie about the current time.
- sildur 6y ago
  That is a very good advice, thank you.
akiselev 6y ago
What do the background tabs do with server side events or websockets? You should be able to just open a connection and send a message over WS or have the server drop the connection on every tick. You can probably do it without a server by hitting an address that will blackhole the connection instead of refusing it and use an AbortController [1] to timeout the request. [1] https://developer.mozilla.org/en-US/docs/Web/API/AbortController https://developer.mozilla.org/en-US/docs/Web/API/AbortContro...
- Aardwolf 6y ago
  The question is mainly about a client-side game, no multiplayer or servers. Here is some context (just a random thread about the issue, threads like this pop up regularly): https://www.reddit.com/r/incremental_games/comments/j86u5m/google_chrome_background_tab_throttling_causing/ https://www.reddit.com/r/incremental_games/comments/j86u5m/g... 5 years ago such games worked in background tabs. Then browsers started throttling background tabs (for understandable reasons) and everyone learned to keep it in a foreground tab in a window you don't use. Now the latter will also stop working.
  - sildur 6y ago
    I'm tired of too-smart browsers, I want a dumb one.
foota 6y ago
Do service workers continue running?
- Aardwolf 6y ago
  Didn't test (yet), but if they do, then what's the point of throttling background tabs?
  - simcop2387 6y ago
    Service workers have restrictions on what they can do. They can't interact with thr dom and a few other things to keep them from causing rendering or other changes.
  - chhamilton 6y ago
    (Chromium dev here.) We don't throttle workers (that could change, but we don't have firm plans here yet). All things being equal, if you move complex work to workers we're happy because it frees up the main thread to handle input events, compositing, etc. Just because your tab is in the background doesn't mean your renderer process isn't sharing a main thread with a tab that is in the foreground, so in this case it can improve foreground tab performance. Also, spreading a fixed amount of work across more cores and fewer wake-ups is actually more efficient from a power point of view (assuming the wake-ups are synchronized).
- chhamilton 6y ago
  (Chromium dev here.) Yes, for now all workers continue to run unthrottled (shared, dedicated and service). They may also be throttled at some point, but we have no firm plans around this yet.

fabian2k 6y ago

You can never rely on the timers firing exactly as you request, so you always have to take the delta since the last timer and use that in your calculations. This is a very basic issues with doing stuff on a timer, and not that hard to do properly. It shouldn't make a difference if your timer is called once per second, once per minute or once in 10 hours in the background, you always calculate based on the delta to the last time your timer fired.

Aardwolf 6y ago
It can be an issue if the game can do complex actions at any time: if you then need to do all of it in one gigantic update after e.g. 24 hours of being in the background, it may take too long to compute that one long tick. Depending on what type of game it is. If it just has to compute "so many resources per second produced" it's easy of course and you can use the delta between last tick (if Date.now() works correctly), but if the game can auto-build various things with complex interactions, it can become computationally complex if it has to do all at once.
- intellix 6y ago
  It sounds like the tab throttling is working as intended then. If I've moved from your game and haven't looked at it then why shouldn't all of that extra computation happen until the next time I'm interested?
  - bobbylarrybobby 6y ago
    For idle games, much of the point is investing in auto-building, then coming back to the game when your investment has borne fruit. For this to work, it has to be able to run in the background.
    - CyberDildonics 6y ago
      There is a big difference between throttling and not running. Still, it is probably much better to sync with the server than run something at full blast to increment some counters.
    - iofiiiiiiiii 6y ago
      Sounds like it's time for the game authors to provide some servers with the compute resources to do this background processing.
- chhamilton 6y ago
  (Chromium dev here.) Doing the work in one giant update is actually better from a power consumption / battery point-of-view, because the CPU cost is fixed but there are fewer wakeups overall. Note that the new throttling logic means you get woken-up once per minute; we're not talking about preventing your page from doing work for a 24 hour period. For full details of how the throttling works, see here: https://www.chromestatus.com/feature/4718288976216064 https://www.chromestatus.com/feature/4718288976216064
nextaccountic 6y ago
But if it lies about Date.now() this isn't possible..
- CyberDildonics 6y ago
  That would be broken and isn't what is being talked about here. There is no reason scheduling as a low priority would mean you need to lie about the current time.
sildur 6y ago
That is a very good advice, thank you.

akiselev 6y ago

What do the background tabs do with server side events or websockets? You should be able to just open a connection and send a message over WS or have the server drop the connection on every tick. You can probably do it without a server by hitting an address that will blackhole the connection instead of refusing it and use an AbortController [1] to timeout the request. [1] https://developer.mozilla.org/en-US/docs/Web/API/AbortController https://developer.mozilla.org/en-US/docs/Web/API/AbortContro...

Aardwolf 6y ago
The question is mainly about a client-side game, no multiplayer or servers. Here is some context (just a random thread about the issue, threads like this pop up regularly): https://www.reddit.com/r/incremental_games/comments/j86u5m/google_chrome_background_tab_throttling_causing/ https://www.reddit.com/r/incremental_games/comments/j86u5m/g... 5 years ago such games worked in background tabs. Then browsers started throttling background tabs (for understandable reasons) and everyone learned to keep it in a foreground tab in a window you don't use. Now the latter will also stop working.
- sildur 6y ago
  I'm tired of too-smart browsers, I want a dumb one.

foota 6y ago

Do service workers continue running?

Aardwolf 6y ago
Didn't test (yet), but if they do, then what's the point of throttling background tabs?
- simcop2387 6y ago
  Service workers have restrictions on what they can do. They can't interact with thr dom and a few other things to keep them from causing rendering or other changes.
- chhamilton 6y ago
  (Chromium dev here.) We don't throttle workers (that could change, but we don't have firm plans here yet). All things being equal, if you move complex work to workers we're happy because it frees up the main thread to handle input events, compositing, etc. Just because your tab is in the background doesn't mean your renderer process isn't sharing a main thread with a tab that is in the foreground, so in this case it can improve foreground tab performance. Also, spreading a fixed amount of work across more cores and fewer wake-ups is actually more efficient from a power point of view (assuming the wake-ups are synchronized).
chhamilton 6y ago
(Chromium dev here.) Yes, for now all workers continue to run unthrottled (shared, dedicated and service). They may also be throttled at some point, but we have no firm plans around this yet.