If it's tab that's already been loaded, then Session restore only does the following on TabSelect: 1. update an index 2. tell crash reporter to update it's current URL (possible that's doing something janky) I don't think there are any setTimeouts in that path in sessionstore. If the tab hasn't been restored then we do that, which does have some expected overhead associated with it. Can you be more specific about which case it is? https://mxr.mozilla.org/mozilla-central/source/browser/components/sessionstore/src/nsSessionStore.js#1201
We're taking screenshots of tabs ~2 secs after they've been selected. So that really might be the culprit. Does the jank still occur when commenting out the following line? http://mxr.mozilla.org/mozilla-central/source/browser/base/content/browser-thumbnails.js#57
(In reply to Paul O'Shannessy [:zpao] from comment #1) > If it's tab that's already been loaded, then Session restore only does the > following on TabSelect: > 1. update an index > 2. tell crash reporter to update it's current URL (possible that's doing > something janky) > > I don't think there are any setTimeouts in that path in sessionstore. > > If the tab hasn't been restored then we do that, which does have some > expected overhead associated with it. > > Can you be more specific about which case it is? This after the session has been restored. Tim's suggestion sounds plausible. It could be a combination of network cache locking and screenshoting. I'll try commenting out that line.
So I was going to try this, but there is no point. My i7 macbook air is probably triggering cache locking issues seen in http://dl.dropbox.com/u/5961467/moz/FX_THUMBNAILS_STORE_TIME_MS.png. Checkout my local histograms: http://dl.dropbox.com/u/5961467/moz/fx_thumbnails_local.png. Both capture time and storing time is terrible.
I suspect a couple of things are inplay here a) slow capture time b) cache locking negating your async efforts while cache entry is written c) doing capture AND write during the same setTimeout Given how expensive drawWindow is, can we do some sort of exponential backoff for users who have slow machines(or don't ever click on thumbnails?)
(In reply to Taras Glek (:taras) from comment #5) > I suspect a couple of things are inplay here > a) slow capture time > b) cache locking negating your async efforts while cache entry is written > c) doing capture AND write during the same setTimeout > Looks c) is not a problem.
P1 as this manifests rather nastily when switching tabs
Whiteboard: [Snappy:P2] → [Snappy:P1]
Whoops, sorry, wrong bug.
tracking-firefox14: ? → ---
Summary: Large jank soon after switching tabs → [Page Thumbnails] Large jank soon after switching tabs
You need to log in before you can comment on or make changes to this bug.