4 ms·

I wonder if this could cause background tabs to develop a large queue of unprocessed events, thus making the tab unresponsive for a while when switching back to

I wonder if this could cause background tabs to develop a large queue of unprocessed events, thus making the tab unresponsive for a while when switching back to it. I used to see this happen on native apps on macOS with App Nap for a while but it seems better on recent versions of macOS.

antihero 6y ago
I see this with the console at least when developing. You switch back to the tab and the console eats shit and locks up because of the back pressure.
- asah 6y ago
  the nice thing with the web is that developers respond reasonably fast (much faster than desktop apps) to changes like this in major browsers...
imtringued 6y ago
This a good point. The application does x amount of work per second in the background. Your browser pauses it for y seconds. According to Google you have saved "x times y times energy per operation". Chrome devs say hurray 5x energy savings. Except when you switch back to the tab you end up spending the same amount of energy to catch up. The primary source of energy savings would be poorly written websites that constantly poll in the background. Games with complicated logic would still consume the same amount of energy.
- chhamilton 6y ago
  (Chromium dev here.) For the most part, events can't really accumulate, because not running code means no new events are posted. The throttling applies to setTimeout/setInterval, and not to any external event (incoming network data, API callbacks, etc). Sites that legitimately have to do a fixed amount of work per unit time (via timers) will simply do that work with 1 wake-up per minute. All things being equal, this still means less battery usage because energy usage is a function of both wakeups and total CPU usage. > The primary source of energy savings would be poorly written websites that constantly poll in the background. This is the key insight here, and really what we're going after. There is a lot of this on the web.

antihero 6y ago

I see this with the console at least when developing. You switch back to the tab and the console eats shit and locks up because of the back pressure.

asah 6y ago
the nice thing with the web is that developers respond reasonably fast (much faster than desktop apps) to changes like this in major browsers...

imtringued 6y ago

This a good point. The application does x amount of work per second in the background. Your browser pauses it for y seconds. According to Google you have saved "x times y times energy per operation". Chrome devs say hurray 5x energy savings. Except when you switch back to the tab you end up spending the same amount of energy to catch up. The primary source of energy savings would be poorly written websites that constantly poll in the background. Games with complicated logic would still consume the same amount of energy.

chhamilton 6y ago
(Chromium dev here.) For the most part, events can't really accumulate, because not running code means no new events are posted. The throttling applies to setTimeout/setInterval, and not to any external event (incoming network data, API callbacks, etc). Sites that legitimately have to do a fixed amount of work per unit time (via timers) will simply do that work with 1 wake-up per minute. All things being equal, this still means less battery usage because energy usage is a function of both wakeups and total CPU usage. > The primary source of energy savings would be poorly written websites that constantly poll in the background. This is the key insight here, and really what we're going after. There is a lot of this on the web.