Sluggish tab opening animation with about:newtab enabled

RESOLVED FIXED in Firefox 16

Status

()

Firefox
Tabbed Browser
RESOLVED FIXED
5 years ago
4 years ago

People

(Reporter: virgil, Assigned: ttaubert)

Tracking

({regression})

13 Branch
Firefox 16
regression
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox13-)

Details

(Whiteboard: fixed by bug 716108)

(Reporter)

Description

5 years ago
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.
tracking-firefox13: --- → ?
OS: Linux → All

Updated

5 years ago
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

Comment 3

5 years ago
(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.
(Reporter)

Comment 4

5 years ago
(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.

Comment 5

5 years ago
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
tracking-firefox13: ? → -

Comment 6

5 years ago
See bug 704882 comment 14 and initial description.

Updated

5 years ago
Duplicate of this bug: 778612

Updated

5 years ago
Depends on: 716108
Bug 778612 suggests that this might be fixed.
Hardware: x86 → All
(Reporter)

Comment 9

5 years ago
(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.

Updated

5 years ago
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
Whiteboard: fixed by bug 716108
Target Milestone: --- → Firefox 17

Updated

5 years ago
Target Milestone: Firefox 17 → Firefox 16

Updated

5 years ago
Duplicate of this bug: 790840
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.