Created attachment 653031 [details]
sample, please open Folder in Bookmarks Menu
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Firefox/17.0 ID:20120817030555
Step To Reproduce:
1. Open several tabs and reload all tabs if necessary
2. Hold Ctrl+Tab
Tab switching is very slow
Tab switching should be smooth.
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Firefox/17.0 ID:20120815053101
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Firefox/17.0 ID:20120815065301
Triggered by: Bug 685516
I can reproduce the delay and confirmed the regression range with local build.
Last Good: a33215aa549c
First Bad: d3829aea9cd1
@TheVisitor provided better STR is in http://forums.mozillazine.org/viewtopic.php?p=12208739#p12208739
0. Open http://forums.mozillazine.org/viewtopic.php?f=23&t=2516363
1. Open http://www.nbcnews.com
2. Open http://www.cnn.com
3. have forum open in a tab
4. switching from the mz forum to either tab 1 or 2 will show about 1 sec delay in switching.
5. if you then quickly switch between the forum and CNN for example - switching is pretty fast.
6. switch to forum tab - wait 10-15 seconds then switch to either CNN or NBCnews - note it lags
In retrospect this isn't that surprising. We now try to decode every image on a page for 5 ms when switching tabs. On a page with lots of large images this could be a pretty significant regression, because we used to not decode any of them immediately. I've noticed this on flickr pages with lots of images.
What we could do is bring back the old "don't sync decode if over a certain size" metric, but keep the "only sync decode for N ms" part for smaller images. How does that sound, Joe?
/me wishes we had OMTD.
Mentioned this to Kyle on irc, but I'll repeat it here: We should have a global limit on the amount of decoding done synchronously on tab switch, with the 5ms adding up to 250 or 500 ms (or whatever, determined by the UX and specified with a pref) and then just queuing up totally-asynchronous decodes after that is reached.
Created attachment 653719 [details]
Slow image display
Is this somehow related?
The test displays 160 small thumbnails.
Rebuilding the image list (innerHTML=) takes almost one second in Nightly, compared to ~30ms in Aurora.
I think comment https://blog.mozilla.org/tglek/2012/08/16/snappy-36/comment-page-1/#comment-35935 is referring to this problem.
Something unrelated to this news: for some days I get real bad hangs, sometimes lasting seconds, mainly while changing tabs. I also tried with a new profile. The gecko profiler always shows something like this:
Yes, that's correct.
What should happen to bug 595927 with this bug open?
(In reply to Mardeg from comment #8)
> What should happen to bug 595927 with this bug open?
I think they're different bugs. This is a regression from bug 685516, the other one is an older regression, without a regression window.
Is disabling animations until we fix them a viable option?
(Currently with animations, if you enable nglayout.debug.paint_flashing, you can see a lot of repaints of the entire chrome when you open or close a tab, without animations there's only a single repaint)
Please stop spamming this bug with unrelated stuff.
This turned out to be caused by bug 784756, which is now fixed, not the scenario in comment 3. Comment 3 is still a theoretical possibility, but I'm not sure that it's common enough for us to invest the effort needed to implement comment 4's solution. I would just WFM this, but I'll give the Snappy folks another chance to weigh in.
(In reply to Kyle Huey [:khuey] (firstname.lastname@example.org) from comment #13)
> This turned out to be caused by bug 784756, which is now fixed, not the
> scenario in comment 3. Comment 3 is still a theoretical possibility, but
> I'm not sure that it's common enough for us to invest the effort needed to
> implement comment 4's solution. I would just WFM this, but I'll give the
> Snappy folks another chance to weigh in.
We can't decide on importance of doing comment 4 without someone diving in for analysis of how much overhead is taken up by image decoding on tab switch. Since bug 753127 is not done, it's not clear whether we regressed our tabswitch speed in bug 685516.
Madhava tells me that, for an interaction to feel instantaneous, the right order of magnitude of time is 100-200ms (depending on what's changing), so I do feel that a 50ms decoding limit is appropriate.
Since we don't have any data to indicate that this is a priority, I doubt we will implement this before off-main-thread-decoding. I'm going to close this as WONTFIX, but feel free to reopen if you disagree.
I have some data (albeit preliminary on nytimes.com) that suggests that tab switch performance can be dominated by image decoding.
Please re-nominate if there's enough data to show significant user pain caused by this.
Alice, does this still reproduce?
With e10s, I can not test this due to Bug 1185667.
Without e10s, It seems to have been improved.