Closed Bug 752839 Opened 13 years ago Closed 12 years ago

Sluggish tab opening animation with about:newtab enabled

Categories

(Firefox :: Tabbed Browser, defect)

13 Branch
defect
Not set
normal

Tracking

()

RESOLVED FIXED
Firefox 16
Tracking Status
firefox13 - ---

People

(Reporter: virgil.dicu, Assigned: ttaubert)

References

Details

(Keywords: regression, Whiteboard: fixed by bug 716108)

http://vid.ly/5g9s7p Screencast taken on a XP machine with a blocked graphics driver. While opening a new tab page the animation feels sluggish on Firefox 13 beta. Seems like the tab is opened in two small steps. there's a stop at one point during loading. Initially reported here: https://bugzilla.mozilla.org/show_bug.cgi?id=724349#c14
I've noticed this as well on Mac. This bug might be a dupe of an existing bug, but the video here illustrates the problem perfectly.
OS: Linux → All
Blocks: 455553
Keywords: regression
I imagine we can end up decoding/drawing the tab thumbnails while the tab animation is still in progress. Short of bug 743069, I wonder what kind of mitigations to this we might try (delaying the load until the tab animation ends may not be any better from a perceived-perf point of view).
Depends on: 753448
(In reply to juan becerra [:juanb] from comment #1) > I've noticed this as well on Mac. This bug might be a dupe of an existing > bug, but the video here illustrates the problem perfectly. Is this a problem with all Mac configs? If not, I don't think a minor UI issue like this with blocklisted graphics drivers warrants tracking.
(In reply to Alex Keybl [:akeybl] from comment #3) > (In reply to juan becerra [:juanb] from comment #1) > > I've noticed this as well on Mac. This bug might be a dupe of an existing > > bug, but the video here illustrates the problem perfectly. > > Is this a problem with all Mac configs? If not, I don't think a minor UI > issue like this with blocklisted graphics drivers warrants tracking. I can also see this issue on Linux, along with Mac and Windows as reported in comment 0 and 1 so this is a more general OS issue - it's just more noticeable on slower computers. There is some comparative data (12-13) that might be useful -collected for Windows XP with about:telemetry in bug 752837 comment 5 both for tab closing and tab opening.
Sending over to Tim to see if there's any quick low-risk perf wins we can make here and uplift to Beta, but this won't block the feature from going out the door. Please nominate any fix you find that meets that criteria.
Assignee: nobody → ttaubert
See bug 704882 comment 14 and initial description.
Depends on: 716108
Bug 778612 suggests that this might be fixed.
Hardware: x86 → All
(In reply to Dão Gottwald [:dao] from comment #8) > Bug 778612 suggests that this might be fixed. I can also confirm this. Bug 752837 comment 38. Fixed by something in that range. It would be great if this can also be confirmed by telemetry data. Bug 724349 was initially logged for the regression and bug 753139 which followed up.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Whiteboard: fixed by bug 716108
Target Milestone: --- → Firefox 17
Target Milestone: Firefox 17 → Firefox 16
Adding some measurements to confirm the improvement of newtab preload on a fast PC, and adding that on a slow PC, preload doesn't help, and animation is still extremely sluggish for me. On a slow PC, it's hard to call it a regression though, when so little frames are actually displayed during this animation. On a fast PC, browser.newtab.preload=true does improve animation smoothness (though still marginally worse than an about:blank page, which I guess is acceptable). - "Preview: yes" is when the 9 placeholders contain website images. - "Preview: no" is when preview is disabled (after clicking the top-right icon of about:newtab). - Both computers running windows 7-x64 with aero theme enabled. - Navigation bar is hidden, mouse is not over the browser, tabs were opened using the KB (ctrl-t). - Measurements were performed with the patch v5 for bug 820167. - Preview:no : performance is practically identical to when browser.newtab.url=about:blank. Slow PC (AMD E-350): -------------------- Preview: yes, preload: yes: Tab open (Frame-interval / paint-processing): 77 / 77 32 / 19 132 / 48 Preview: yes, preload: no: Tab open (Frame-interval / paint-processing): 12 / 12 31 / 14 139 / 27 47 / 15 21 / 11 Preview: no, preload: yes: Tab open (Frame-interval / paint-processing): 12 / 11 30 / 14 36 / 14 25 / 12 14 / 11 13 / 12 13 / 11 12 / 11 12 / 11 11 / 10 12 / 11 12 / 9 19 / 10 15 / 9 19 / 10 Fast PC (i7-3630qm): -------------------- preview: yes, preload: yes: Tab open (Frame-interval / paint-processing): 23 / 22 10 / 5 25 / 8 30 / 8 15 / 5 10 / 5 14 / 4 10 / 4 10 / 5 17 / 4 17 / 4 17 / 4 17 / 4 18 / 4 17 / 5 preview: yes, preload: no: Tab open (Frame-interval / paint-processing): 11 / 11 11 / 4 69 / 9 33 / 5 13 / 4 42 / 34 15 / 5 15 / 12 8 / 8 7 / 7 10 / 8 16 / 6 preview: no, preload: yes: Tab open (Frame-interval / paint-processing): 8 / 8 8 / 4 10 / 4 10 / 4 17 / 3 17 / 3 17 / 4 16 / 4 17 / 4 16 / 4 17 / 4 17 / 4 20 / 7 17 / 8 16 / 8 16 / 8
You need to log in before you can comment on or make changes to this bug.