The default bug view has changed. See this FAQ.

Newtab page slows down tab-open animation

RESOLVED FIXED in Firefox 24

Status

()

Firefox
Tabbed Browser
RESOLVED FIXED
4 years ago
4 years ago

People

(Reporter: avih, Assigned: ttaubert)

Tracking

(Depends on: 1 bug)

unspecified
Firefox 24
x86_64
Windows 7
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [snappy:p1])

Attachments

(1 attachment, 1 obsolete attachment)

(Reporter)

Description

4 years ago
Tab animation smoothness telemetry suggests that the newtab page with thumbnails preview hurts animation smoothness.

Telemetry: http://goo.gl/LHjTZ (top: no newtab open without preview, bottom: with thumbnails preview).

There's also tab animation logs on bug 752839 comment #11 with and without thumbnails preview on slow/fast systems, with and without newtab preload.

The data suggests that on slow systems the FPS is really bad when preview is enabled, regardless of preload.

Updated

4 years ago
Assignee: nobody → ttaubert
Whiteboard: [snappy:p1]
Is this effect changed (for better or worse) by toggling browser.newtab.preload?
(sorry, never mind me, I clearly can't read comment 0)
(Assignee)

Comment 3

4 years ago
So I tested a couple of things with my brand-new (and slow) netbook. I rewrote the benchmark script a little to show the median of frames the tabopen animation consisted of. The more frames, the better.

1) Having about:blank as the new tab page yields 15 frames. That's obviously the goal.
2) The unchanged version of about:newtab (the one we currently ship) yields 3 frames (boo).
3) The thumbnail grid is inserted into the DOM dynamically. If I comment out this part so that the grid will never render we go up to 8 frames.
4) Keeping the change from (3) and commenting out the static XUL/HTML - the scrollbox and margins - we go up to 14 frames. Looks like there's a whole lot of overhead involved in layout/rendering the XUL flexbox elements here.

I wonder if the CSS3 flexbox model might be a better fit here? Is that optimized somehow? Another solution may be to defer rendering the page until the tabopen animation has finished? I'm not sure how this feels when opening a new tab. Also, preloading the new tab page does not seem an option then anymore.
(In reply to Tim Taubert [:ttaubert] from comment #3)
> I wonder if the CSS3 flexbox model might be a better fit here? Is that
> optimized somehow?

It seems like something is going wrong here. I'd suggest profiling the different cases to try to find out where the extra time is actually being spent and hopefully that will give a better indication of what to fix.
Rewriting the tab page to use CSS3 flexbox is a good idea since that's the future anyway. I'd rather optimize that layout code than the XUL code, which is both obsolete and insane.
(Assignee)

Comment 6

4 years ago
Ok, something regressed this even more on my netbook. Using about:blank once yielded 15 frames for the tabopen animation to finish and I can still achieve this with a build from Feb 27th. With a current trunk build we're down to 7 frames :(
(Assignee)

Comment 7

4 years ago
Looks like this is caused by bug 844466.
Blocks: 844466
(Assignee)

Comment 8

4 years ago
What bug 844466 does is start the tabopen animation synchronously instead off a timeout. I have no idea why that would regress on my slow netbook but I'm still seeing the 15 frames on my quad core machine, so there must be something that hurts us.

Comment 9

4 years ago
(In reply to Tim Taubert [:ttaubert] from comment #8)
> What bug 844466 does is start the tabopen animation synchronously instead
> off a timeout. I have no idea why that would regress on my slow netbook but
> I'm still seeing the 15 frames on my quad core machine, so there must be
> something that hurts us.

Avi we should setup an automatic test for this
(Reporter)

Comment 10

4 years ago
(In reply to Taras Glek (:taras) from comment #9)
> Avi we should setup an automatic test for this

Bug 848358.
(Assignee)

Updated

4 years ago
Depends on: 850163

Updated

4 years ago
No longer blocks: 844466
(Assignee)

Comment 11

4 years ago
Created attachment 735295 [details] [diff] [review]
delay rendering the newtab page until the tabopen animation has finished

Here's a proposed fix that delays the rendering of about:newtab until after the tabopen animation has finished. The perf measurement values are close to about:blank with that on my machine but it doesn't look quite as nice when playing around with it. Although it's definitely an improvement over the current state of things.
(Assignee)

Comment 12

4 years ago
Created attachment 735299 [details] [diff] [review]
(WIP) convert the newtab page to XHTML and use the CSS3 flexbox model

This patch is work in progress. It converts newTab.xul to an XHTML page and uses the CSS3 flexbox model. Interestingly, we're a little faster in painting about:newtab but the tabclose animation is totally botched. I have no idea if we maybe miss a couple of optimizations when destroying HTML flexbox layouts?
(Assignee)

Comment 13

4 years ago
Comment on attachment 735295 [details] [diff] [review]
delay rendering the newtab page until the tabopen animation has finished

Try builds should be available soon:

https://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/ttaubert@mozilla.com-2875261de9fa/
(Reporter)

Comment 14

4 years ago
(In reply to Tim Taubert [:ttaubert] from comment #13)
> Comment on attachment 735295 [details] [diff] [review]
> delay rendering the newtab page until the tabopen animation has finished

Tim and I discussed this a bit on IRC. We thought the delay approach could be useful on slow systems, but we don't want to delay rendering on fast systems - where it's not required. Also, on slow systems, we might want to also disable newtab preload (waiting on bug 791670), because measurements show that it doesn't help on slow systems (but then again, it might also not matter at all when delaying the rendering).

If this is how we decide to go forward, then we'll need to instrument tab animation at runtime, and decide if we do or don't use delay - based on those results. Or we could use HW blacklisting, but I personally prefer run time instrumentation, especially since the infrastructure (and telemetry - bug 828097) is already there.

There's already bug 787698, which also assumes performance based decision, but on that bug, the suggestion is to disable tab animation altogether on slow system.

I personally prefer delayed preview rendering over disabled animation. Any comments on this approach? If we decide on runtime detection, then I'll file a bug for it.
(Reporter)

Comment 15

4 years ago
(In reply to Tim Taubert [:ttaubert] from comment #12)
> Created attachment 735299 [details] [diff] [review]
> (WIP) convert the newtab page to XHTML and use the CSS3 flexbox model
> ... It converts newTab.xul to an XHTML page and
> uses the CSS3 flexbox model. Interestingly, we're a little faster in
> painting about:newtab ...

How much faster?

Also, taras reminded me that we still don't really understand what's so slow with the current newtab rendering. It could be an existing bug someplace, or some other deficiency which could be improved/bypassed, but until we actually know what's slow there, we can't approach this efficiently.

Delaying the rendering could be a reasonable workaround if we decide it can't be improved, but finding the actual culprit would probably be a better first step.
This depends on bug 791670 now, right?
(Assignee)

Comment 17

4 years ago
Yes, exactly.
Depends on: 791670
OS: Windows 7 → All
Hardware: x86_64 → All
Version: unspecified → Trunk
(Assignee)

Comment 18

4 years ago
Adding bug 853833 as a dependency (which in turn depends on bug 719177). Hovering one of the thumbnails in about:newtab triggers a reflow (it shouldn't). This potentially also affects the tabopen animation if the cursor happens to be in the area of one of the thumbnails.
Depends on: 853833
OS: All → Windows 7
Hardware: All → x86_64
Version: Trunk → unspecified
Tim: do you have numbers for the impact of bug 791670 on this, now that all the reflow-causing things have been fixed?
(Assignee)

Updated

4 years ago
Attachment #735295 - Attachment is obsolete: true
(Assignee)

Comment 20

4 years ago
Measured with a build from today on my slow netbook:

about:blank  = Interval: 20.3ms, Paint:  8.1ms, Frames: 12
about:newtab = Interval: 21.3ms, Paint: 34.0ms, Frames: 11

We started with a frame count of 3 without newtab page preloading. We're almost on a par with about:blank now. We need a little more time to paint which is understandable though because there actually is something to be painted in about:newtab. Resolving as fixed.
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 24
You need to log in before you can comment on or make changes to this bug.