With bug 1476981 we are lowering priority of processes whose tabs are all in the background, thereby allowing the foreground tab to get more CPU cycles. With increased processes this effect will be even more pronounced as more tabs will qualify.
With Fission we now have multiple processes being represented in each tab via iFrames.

Let's also consider lowering priority of iFrame processes that are currently off screen in the current page.

If for some reason responsiveness is a concern, for instance checkerboarding when scrolling quickly, note that Windows has multiple priority settings:
https://docs.microsoft.com/en-us/windows/desktop/api/processthreadsapi/nf-processthreadsapi-setpriorityclass

This is a bit tricky because AFAIK there is no notion of an iframe process. We will allocate OOP-iframes to processes by their origin. So an OOP-iframe may share a process with a top-level window.

Regardless, we could use BrowserParent::mEffectsInfo.IsVisible() to determine if an OOP-iframe is visible in it's embedded document or not [1].

[1] https://searchfox.org/mozilla-central/rev/1133b6716d9a8131c09754f3f29288484896b8b6/dom/ipc/EffectsInfo.h#36

Ah, gotcha, there may be more than one iframe/tab running in a process. So if one or more of those are visible, we can't deprioritize the process, but if all are hidden, then maybe we could.

Sorry for the double comment spam, but perhaps it would be valuable to have numbers on how many iframes and associated processes are hidden at any given time.

I know for me most tabs are in the background at any given time.

hi @mccr8, Is this a dup of the work you did in process priority manager?

I don't think it is. The work I did was about properly changing the priority of iframes in background tabs, while this appears to be about adjusting the priority of iframes in the foreground tab, that happened to be scrolled out of view. It would require some additional work because right now we only track the active state of the top level browsing context, whereas with this you'd need to track the active state of every browsing context.

I haven't thought about this in too much detail, but it feels like this would be higher risk (the foreground page might be able to interact with an iframe even if it isn't being displayed) and lower reward (because only one tab per window is in the foreground) than dealing with background tabs.