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; - ... Note that, going a little further, this idea can be generalized to a mini-scheduler API with simple real time constraints. Whether this is a good idea or not remains to be discussed. Cheers, David -- David Rajchenbach-Teller, PhD Performance Team, Mozilla
signature.asc
Description: OpenPGP digital signature
_______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
