3 ms·

> Tab throttling coming to Beta This is nice, but I remember the pain trying make a multiplayer browser game run fine, even when you put it in a background tab

by XCSme 6y ago

> Tab throttling coming to Beta This is nice, but I remember the pain trying make a multiplayer browser game run fine, even when you put it in a background tab. The problem is that the game had matchmaking, so players would change tabs while a match was found and for the first few seconds of the start of the game. While doing so, many of the CSS animations, sounds, JavaScript functions would be queued and all executed at once when you switched back to the tab, leading to a bad experience, or in some cases the game breaking. I assume this would only get worse with this tab throttling feature, but there are legitimate use cases where both developers and users would prefer a tab to still be running at normal speed even when not focused. We use this every day in desktop applications, where we start a game or some video encoding task and just let it run, non-throttled, in the background

londons_explore 6y ago
As a developer, you probably ought to just send a message to the server saying "I am throttled", and then later when the tab is reactivated send another message saying "I am unthrottled, please send me the current state of the game". You shouldn't be expecting to queue up thousands of messages from potentially hours of the tab being backgrounded and handle them all when the tab is unbackgrounded. Nor should you process all the state changes as they come in even though the tab is backgrounded - no user wants to spend data/power/cpu/battery/heat on something like that.
- XCSme 6y ago
  That's a good solution if your game receives game states, but in our case the game was deterministic and ran the simulation on the client at 50FPS, only receiving the inputs from other players. This means that if your game freezes for 10 seconds (or tab out for 10 seconds), when you go back it would have to simulate all those 10 seconds before it could continue. Imagine having GTA 5 multi-player running in a background window, you would still want to hear the other people, hear the in-game sounds so you can come back to the game if something important happens, and also not have to simulate instantly all the events that you missed when you come back. This also reminded me that we had problems with just playing a sound when a game started to let the players know they should come back to the tab. Players complained that sometimes the game does not notify them it has started, but it was just Chrome simply not executing JavaScript anymore.
  - londons_explore 6y ago
    I think the Chrome developers are trying to tell you you shouldn't be using your users devices as game servers... How about when a tab is backgrounded, a server continues running the game and just streams an mp3 audio stream to the users device. Most devices can stream audio with the CPU actually turned off.
    - XCSme 6y ago
      The devices are used as game clients, not game servers. Streaming audio sounds like an interesting idea, so instead of the server sending an event and the client playing a sound when that event is received, the client would constantly stream a dynamically created audio file. This solution could work, feels a bit complex as you would still have to make sure stream catches up if user has a lag spike, instead of buffering the audio (timing should still be accurate). That being said, what it the game is single-player and there is no server? Then the client itself would have to generate the audio stream and stream it to itself, which wouldn't work if the background thread is throttled.
  - setr 6y ago
    >That's a good solution if your game receives game states, but in our case the game was deterministic and ran the simulation on the client at 50FPS, only receiving the inputs from other players. This means that if your game freezes for 10 seconds (or tab out for 10 seconds), when you go back it would have to simulate all those 10 seconds before it could continue. I would imagine you could do a "catch-up" mode -- execute the simulation at uncapped FPS till the simulation reaches parity, and turn off ui/sounds/etc during it. Actually, if you didn't have such a mode already, I'm not clear on how the simulation would ever be able to catch up (eg most RTS's won't let you rejoin a match due to this)
- XCSme 6y ago
  > You shouldn't be expecting to queue up thousands of messages from potentially hours of the tab being backgrounded and handle them all when the tab is unbackgrounded. In this specific case, the games only lasted 3-4 minutes each and players were also timed-out after periods of inactivity. > Nor should you process all the state changes as they come in even though the tab is backgrounded - no user wants to spend data/power/cpu/battery/heat on something like that. In the case of games, players do expect multiplayer games to keep running (unless it is paused, and you can't usually pause multiplayer games). Yes, I agree that the game could optimize this AFK period, for example by disabling rendering, but game events should still be triggered in real-time and notify players (with sound at least) of what's happening. My point is, there are cases when a browser background tab should still run at 100%. Other examples: uploading a video to YouTube in a background tab, running a chess engine to get best move in a position, converting a video, etc.

by XCSme 6y ago

londons_explore 6y ago

As a developer, you probably ought to just send a message to the server saying "I am throttled", and then later when the tab is reactivated send another message saying "I am unthrottled, please send me the current state of the game". You shouldn't be expecting to queue up thousands of messages from potentially hours of the tab being backgrounded and handle them all when the tab is unbackgrounded. Nor should you process all the state changes as they come in even though the tab is backgrounded - no user wants to spend data/power/cpu/battery/heat on something like that.

XCSme 6y ago
That's a good solution if your game receives game states, but in our case the game was deterministic and ran the simulation on the client at 50FPS, only receiving the inputs from other players. This means that if your game freezes for 10 seconds (or tab out for 10 seconds), when you go back it would have to simulate all those 10 seconds before it could continue. Imagine having GTA 5 multi-player running in a background window, you would still want to hear the other people, hear the in-game sounds so you can come back to the game if something important happens, and also not have to simulate instantly all the events that you missed when you come back. This also reminded me that we had problems with just playing a sound when a game started to let the players know they should come back to the tab. Players complained that sometimes the game does not notify them it has started, but it was just Chrome simply not executing JavaScript anymore.
- londons_explore 6y ago
  I think the Chrome developers are trying to tell you you shouldn't be using your users devices as game servers... How about when a tab is backgrounded, a server continues running the game and just streams an mp3 audio stream to the users device. Most devices can stream audio with the CPU actually turned off.
  - XCSme 6y ago
    The devices are used as game clients, not game servers. Streaming audio sounds like an interesting idea, so instead of the server sending an event and the client playing a sound when that event is received, the client would constantly stream a dynamically created audio file. This solution could work, feels a bit complex as you would still have to make sure stream catches up if user has a lag spike, instead of buffering the audio (timing should still be accurate). That being said, what it the game is single-player and there is no server? Then the client itself would have to generate the audio stream and stream it to itself, which wouldn't work if the background thread is throttled.
- setr 6y ago
  >That's a good solution if your game receives game states, but in our case the game was deterministic and ran the simulation on the client at 50FPS, only receiving the inputs from other players. This means that if your game freezes for 10 seconds (or tab out for 10 seconds), when you go back it would have to simulate all those 10 seconds before it could continue. I would imagine you could do a "catch-up" mode -- execute the simulation at uncapped FPS till the simulation reaches parity, and turn off ui/sounds/etc during it. Actually, if you didn't have such a mode already, I'm not clear on how the simulation would ever be able to catch up (eg most RTS's won't let you rejoin a match due to this)
XCSme 6y ago
> You shouldn't be expecting to queue up thousands of messages from potentially hours of the tab being backgrounded and handle them all when the tab is unbackgrounded. In this specific case, the games only lasted 3-4 minutes each and players were also timed-out after periods of inactivity. > Nor should you process all the state changes as they come in even though the tab is backgrounded - no user wants to spend data/power/cpu/battery/heat on something like that. In the case of games, players do expect multiplayer games to keep running (unless it is paused, and you can't usually pause multiplayer games). Yes, I agree that the game could optimize this AFK period, for example by disabling rendering, but game events should still be triggered in real-time and notify players (with sound at least) of what's happening. My point is, there are cases when a browser background tab should still run at 100%. Other examples: uploading a video to YouTube in a background tab, running a chess engine to get best move in a position, converting a video, etc.