Counter-intuitively, having multiple content processes may use less memory than taking screenshots per tab. Especially if we use the same COW forking FFOS uses the overhead of a content processes should be very small, certainly less than a high resolution screenshot kept around. Not sure do what degree we can replicate on Windows what we do on FFOS to launch content processes. Why don’t we use more than 1 content process by default right now?
Thanks, Andreas > On Apr 7, 2015, at 12:50 PM, Ted Mielczarek <t...@mielczarek.org> wrote: > > On Tue, Apr 7, 2015, at 11:05 AM, Bill McCloskey wrote: >> On Tue, Apr 7, 2015 at 5:48 AM, Benjamin Smedberg <benja...@smedbergs.us> >> wrote: >> >>> With desktop e10s on there can be a noticeable delay after switching tabs >>> where there is a throbber displayed before the page content. >>> >> >> When the user switches tabs, we allow the content process 300ms to send >> layer information to the parent. During that time, we show the previous >> tab. If no layers are received after 300ms, we show the spinner. >> >> >>> Is the duration of this delay measured in telemetry anywhere, and do we >>> have criteria for how much delay is acceptable in this case? If e10s were >>> off, do we expect that this same delay would occur but would just show up >>> as a jank switching tabs? Or is this a perf problem unique to e10s? >>> >> >> We don't have telemetry yet. I've done some measurements and haven't >> found >> any cases where tab switching consistently takes longer in e10s. However, >> it's certainly possible that it does on average. Either way, it's hard to >> investigate until we can reproduce the problem. >> >> The switch is definitely more noticeable in e10s because non-e10s would >> just jank. A spinner (especially a low-quality animated gif like the one >> we >> have) is easier to notice than jank. We've considered a couple options > > So, assuming there's content script eating up cycles, right now the e10s > case will essentially always be worse than the non-e10s case, right? In > the non-e10s case the chrome JS for switching tabs will get hung up and > result in jank, but then when it gets to run the repaint should be very > fast because the layer tree is in-process. In the e10s case the chrome > JS will run, then we wait on IPC for the layer tree which will be held > up by the content JS, then we have to transmit the layer tree via IPC, > and only then can we paint. > > Short of doing the layer IPC on a different IPC channel this doesn't > seem fixable. Alternately we could focus on running >1 content process > as others have noted, since that limits the content script problem to > tabs running in the same process as the tab you're switching to. > > -Ted > _______________________________________________ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
