throttle timers foreground tabs in blurred windows after a timeout |
||
Issue descriptionIt looks like Safari already does this according to issue 760774 , which implies a certain degree of web compatibility. With other throttling we're doing we're intending to throttle all tasks eventually. I'm not as confident we can do that for tabs in visible windows, so I'd suggest we start conservative and just to timers. panicker, japhet, or hiroshige: This might be a good scheduling task to take on when you're done with your current projects. I suspect we can avoid doing an intent process here since this is more of a tweak to existing behavior than something new. It looks like the 90%ile of number of windows open is >3 and 99%ile is >7, so this probably would have a reasonably big impact. https://uma.googleplex.com/p/chrome/histograms/?endDate=20170907&dayCount=1&histograms=Tabs.MaxWindowsInADay&fixupData=true&showMax=true&filters=platform%2Cone_of%2CC%7CL%7CM%7CW%2Cchannel%2Ceq%2C1%2Cisofficial%2Ceq%2CTrue&implicitFilters=isofficial
,
Sep 8 2017
This is basically throttling in PASSIVE state and could be formalized in Web Lifecycle.
,
Sep 9 2017
Yup
,
Sep 11 2017
Tying this to user interaction (rather than animations) seems like the way to go. One thing we're not sure about yet is what to do with sites playing (non-audible) video. We could opt-out on video playback, but that would get triggered by a bunch of ads too. (Crazy idea: detect the area of the window that's changing and use a size threshold to enable/disable throttling) Another thing I'm not sure yet about here is how much we can win by doing this: how often do users leave unattended windows laying around. The first step here might be to add some metrics and decide (ideally in advance) how prevalent this should be for us to care.
,
Sep 11 2017
Anecdata here: I was on a road trip this weekend, using my laptop (I was a passenger). I was mostly working in Visual Studio, photoshop, a video editor, and various other programs. Chrome was open because I never close Chrome. I noticed that some Chrome processes were using a bit more CPU time than I was happy with, especially the visible tab (and the browser and GPU processes). I decided to open a new tab and leave the NTP active as a life-hack to force the busy tab to be throttled. I could also have minimized Chrome, but I shouldn't have to do either. In this scenario (Chrome not the active application, on battery power) it seems intuitive that Chrome should be throttled immediately. If it's a common scenario then it could save a nice bit of power, if it's not a common scenario then it at least does no harm. Another anecdata is that my daughter informs me that she and her peers (university students) tend to have one top-level Chrome window open for each subject they are taking, as a way to collect related tabs they are using for research. So, that's a half-dozen or so top-level windows that are currently not being throttled. It sounds like this is a common power-user scenario with a potentially huge impact. What do you mean by "blurred windows" - is that Mac-speak for inactive windows?
,
Sep 11 2017
Issue 760774 has been merged into this issue.
,
Aug 17
|
||
►
Sign in to add a comment |
||
Comment 1 by ojan@chromium.org
, Sep 8 2017