Chrome will aggressively throttle background tabs

Re:Chrome will aggressively throttle background tabs by daveheq on Tuesday January 24, 2017 @05:27PM (#13476341)

Why should the browser rely on the webpage developer to tell it to not redraw things in a tab that isn't the visible one? The browser by default shouldn't redraw content in a tab that isn't visible. This seems like the most obvious thing in the world.

[ Parent | on HN ]

Re:Chrome will aggressively throttle background tabs by Filligree on Tuesday January 24, 2017 @05:33PM (#13476387)

It depends on how you define "Visibility changes".

What might he be talking about? Well, it works something like this...

- The app fetches data from a server.

- The data is processed. This may be cheap, or expensive.

- The DOM is updated.

- The page layout is recomputed.

- The browser window is redrawn.

Certainly, the browser could skip the last step for invisible tabs. It can't skip redoing the layout, as the JS can read the computed layout back out; at most it could do the computation lazily, but that would be extra code and complexity. Everything prior to that step isn't under the browser's control.

The web-app coder could act on every single step in the chain, starting by throttling data fetches.

[ Parent | on HN ]

Re:Chrome will aggressively throttle background tabs by odbol_ on Tuesday January 24, 2017 @09:17PM (#13477854)

Because some websites might still need to work when not in focus. E.g. If you are showing animations or videos in a window, but the user wants to answer an IM in another window without interrupting the animations.

[ Parent | on HN ]

Re:Chrome will aggressively throttle background tabs by 72deluxe on Wednesday January 25, 2017 @07:45AM (#13480924)

But then if you switch windows or tabs, the timer for the animations in the tab that is now invisible can be stopped, surely??

Why redraw an invisible window? In any ordinary paint routine, you query for the invalidated rectangle and only redraw what you must. In the case of pages that are out of view, then nothing needs redrawing.

Processes that are busy doing things they need not (like redrawing on a timer, polling a mouse) is why Apple starting highlighting offenders in macOS (what is hogging the battery??) and why I don't use Chrome on it - it just gobbles power keeping all of those tabs alive.

Hopefully these new changes will help.

[ Parent | on HN ]

Re:Chrome will aggressively throttle background tabs by artursapek on Wednesday January 25, 2017 @09:19AM (#13481497)

OP here. In my case, the CPU saved was mostly React updating its virtual DOM. Yes, the browser doesn't do repaints when the tab is in the background. But there's plenty of other work that is done before repaints when using a library like React.

[ Parent | on HN ]

Re:Chrome will aggressively throttle background tabs by vertex-four on Tuesday January 24, 2017 @05:31PM (#13476371)

It doesn't need to do the final step of rendering - but it still needs to reflow the page whenever you change the DOM, because information from that reflow is accessible to javascript.

[ Parent | on HN ]