We should throttle foreground tabs in windows that are completely occluded the same way as we throttle backgrounded tabs. In both cases the user cannot directly observe the web contents (module audio playback), so throttling could be used to save power.
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.
Sorry for the inconvenience if the bug really should have been left as Available. If you change it back, also remove the "Hotlist-Recharge-Cold" label.
For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Yes, I'm actively working on this.
I created aura::WindowOcclusionTracker to track the occlusion state of tabs. I'm now working on using signals from aura::WindowOcclusionTracker to throttle execution and disable rendering in occluded tabs.
For the record, message from yusukes@:
Is there a plan to limit CPU usage of foreground Chrome renderer process(es) with either RenderProcessHostImpl::UpdateProcessPriority(), ChildProcessLauncher::SetProcessPriority(), or base::SetProcessBackgrounded() when their Chrome browser window(s) are completely covered by another window? This seems like a good thing to make sure a maximized/fullscreen ARC++ window can use 100% of CPU time.
François, could you let me know the current status of this bug? I'd especially like to know if issue 788827 (ARC++ cpu usage issue) has already been fixed or not. Thanks.
fdoray@, sorry for pinging you again but what's left for this? Is this mostly working already, or are these still some missing pieces? There's no activity for like 2-3 weeks.
Comment 1 by skyos...@chromium.org
, Nov 25 2016