On Sun, Jun 28, 2015 at 10:09:04PM +0200, David Rajchenbach-Teller wrote: > On 28/06/15 20:39, Randell Jesup wrote: > >>> I was under the impression that because e10s is only a single process for > >> all content (at least right now) a background tab can still negatively > >> affect the foreground tab. > >> > >> That's right, but we also tested e10s in the process-per-tab configuration > > > > There are other options for background tab effects on foreground, though > > all have some sort of impact. (For example, you could 'freeze' > > background tabs more aggressively than we currently do. This may have > > some impact on functionality - we already limit timeouts, but IIRC we > > don't turn them off entirely, and other events still occur that we could > > defer until the tab is touched or ignore - but again, that could cause > > sites to break or make switching back problematic/annoying. However, > > I'm out of touch with the exact state of our 'freezing' of background > > tabs. And there are certainly sites where they'll eat your performance > > (eventually) unless you block everything. > > Actually, I was just thinking about introducing a "priority-to-60fps" > mode, activated e.g. while the user is scrolling the foreground tab, or > perhaps during animations in the foreground tab. > > Whenever we are running in "priority-to-60fps" mode, we can delay up to > N milliseconds main thread treatments such as: > - garbage-collection/cycle-collection; > - dispatching events to background tabs (including timeouts); > - Session Restore; > - Thumbnail creation; > - FHR; > - Sync; > - db flushes; > - copying large batches of data to worker threads; > - performance monitoring; > - ...
BTW, wasn't there an effort a few couple years ago, to move content event loop in different threads for different tabs? What happened to that? Mike _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
