Issue metadata
Sign in to add a comment
|
Switching tabs freezes multiplayer games
Reported by
a...@scirra.com,
Dec 20 2016
|
||||||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.87 Safari/537.36 Steps to reproduce the problem: Construct 2 (www.scirra.com) uses WebRTC Datachannels to run multiplayer games. It uses peer-to-peer connections and assigns one of the players as the host. The host essentially acts as the server. However if the host switches to a different tab Chrome suspends the tab which is hosting the multiplayer game, essentially hanging the server, so the game freezes for all players. This makes Chrome unreliable as a browser for peer-to-peer multiplayer games. What is the expected behavior? This was an issue in the past, but we started using a workaround: we spin up a web worker, and set that to postMessage to the main window every 16ms to wake it up and keep processing the game. This worked for a couple of years, but stopped working recently, and now users are upset: https://www.scirra.com/forum/multiplayer-fails-when-host-browser-is-minimized_t184285 I suppose Google's ongoing work to save battery life and system resources has made tab suspends more aggressive and has now blocked our workaround. What went wrong? I know that one of Google's priorities is to stop bad-citizen background tabs from draining battery/CPU, but hosting interactive content with WebRTC surely must qualify as an exception. It's not really an attractive idea to make multiplayer browser games if they could be suspended at any time. Did this work before? Yes Not sure - only changed recently, past few months Does this work in other browsers? N/A Chrome version: 55.0.2883.87 Channel: stable OS Version: 10.0 Flash Version: Shockwave Flash 24.0 r0 This is a repost of issue 345281 since our workaround has stopped working. IIRC last time a Google engineer suggested to move the game itself in to a web worker. This is an unsatisfactory solution for a couple of reasons: - games have demanding multimedia requirements, and APIs like Web Audio are still unavailable in a worker, making such a move extremely difficult - if web developers are supposed to move heavy/on-going work in to a Worker, then won't Chrome eventually suspend workers in background tabs as well? It's the same situation as now, except code is running somewhere else. There will be the same motivation to save power and system resources. - such a move is a huge project for us involving a ton of refactoring, and it's not clear that the solution will even be permanent, given Chrome could well end up with the motivation to suspend web workers as well. (Maybe it does already - I don't know) In short we need a reliable way to keep a WebRTC host running even when in the background.
,
Dec 28 2016
,
Dec 29 2016
,
Jan 3 2017
,
Jan 3 2017
,
Jan 3 2017
Applying Blink>Workers component since that seems more appropriate for this bug than Blink>WebRTC. Blink>Workers team, please triage further if you are not the right fit for this.
,
Jan 3 2017
Note that workers are only involved as our hack to keep the tab alive in the background. Ideally there would be a clearer way to do this, e.g. a "stay awake in background" API.
,
Jan 5 2017
Added "Blink>Scheduling" (Worker tasks associated with a background tab can be throttled by per-frame task scheduler)
,
Jan 5 2017
,
Jan 5 2017
I don't think issue 667272 is quite the right bug for resolving this use case. Indeed the immediate reason for this issue is that workers are now throttled by the scheduler (what milestone did that start in?) but this is by design. Issue 667272 shares this immediate reason but the resolution there appears to be to not throttle when Web Audio is involved. But for this bug in particular: > we spin up a web worker, and set that to postMessage to the main window every 16ms to wake it up and keep processing the game. This workaround will no longer work by design. I see some possible ways forward here: - Teach the scheduler that background tabs using WebRTC should not be throttled, like Web Audio. (I don't know enough about WebRTC to know if this is the correct decision.) - Design a web platform API for a site to request permission to run "heavily" in the background and not get throttled. - Alternatively, make the scheduler intelligent enough (using site engagement?) to automatically detect when it shouldn't throttle. - Declare this use case (a background tab doing real-time unthrottled tasks) to be unsupported. But I believe from the point of view of Blink>Workers, this throttling is working as intended. Therefore I'm kicking back to Scheduling and WebRTC.
,
Jan 10 2017
My first reaction here is that we might want to create a user permission to run as a background tab. The user would get prompted that the site might user a lot of battery even when backgrounded. We'd obviously need to run this by UX. Alternately, as a short-term stop-gap, we could create an opt-out from throttling. But, that would be a short-term solution at best.
,
Jan 10 2017
,
Jan 10 2017
skyostil@ I thought we didn't throttle worker threads?
,
Jan 10 2017
Sorry, my comment at #8 was misleading. The per-frame task scheduler does NOT throttle tasks running on Worker (see issue 670534 ), but can throttle tasks posted from Worker to parent Document (e.g, postMessage, resource request). In the case of the original report, postMessage() seems to be throttled.
,
Jan 10 2017
That's right, worker threads currently run completely unthrottled. I wonder if we should treat the usage of WebRTC similarly to audio playback and avoid throttling in that case? I guess the risk is that if WebRTC is used a lot, we end up not throttling in many cases.
,
Jan 25 2017
I don't think WebRTC is that widely used. I've read elsewhere having an active WebSocket connection will prevent a tab being suspended/throttled (or this is planned) - if that's the case it seems logical to extend that to WebRTC DataChannels.
,
Mar 13 2017
pthatcher - does this problem sound familiar?
,
Mar 17 2017
In Chrome 57 postMessages are not throttled, so this use case should work fine for now (can you confirm it, please?). We will revisit postMessage throttling at some point in the future. We are looking into different options with regard to background tabs and are trying to find the right balance. My personal favourite option (not a guarantee of any sorts) is to allow WebWorker to run in the background, but require an explicit user permission for this. Suggestions are appreciated here.
,
Mar 31 2017
ash@ would you be able to re-test in M57 as suggested in #18?
,
Mar 31 2017
The steps in issue 345281 (using http://www.scirra.com/labs/multiplayer/test1/) does not reproduce any more in Chrome 57. Looks OK now!
,
Mar 31 2017
I'm still a bit worried this will regress again in future, though. Please bear in mind WebRTC as an exemption from throttling.
,
Mar 31 2017
It's one of the use cases we're consider when extending background tab throttling in the future: https://docs.google.com/document/u/1/d/16-QGneIkYNbNleoXbdD-mRMYdZAG2JIjMcTVxSC3ZWc/edit Here's a test to make sure WebRTC keeps working: https://cs.chromium.org/chromium/src/third_party/WebKit/Source/web/tests/ActiveConnectionThrottlingTest.cpp
,
Apr 6 2017
Great, thanks for re-testing! I'll close this, but feel free to re-open (or file a new bug) if a regression happens in the future. |
|||||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||||
Comment 1 by ajha@chromium.org
, Dec 21 2016