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 for tab switching in bug 1111632 that would improved perceived response time. One is to cache the tab's background color and show that. Another is to show some sort of screenshot of the tab, although that probably won't work because it would take too much memory. I think we probably want to use a longer delay than 300ms before we show the spinner. We'd also like to look into why it takes so long to re-create the layer tree when we switch to a tab. Sometimes it's caused by a janky content process, but there may be some layout/gfx improvements we could make too. -Bill _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform