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.
Is this effect changed (for better or worse) by toggling browser.newtab.preload?
(sorry, never mind me, I clearly can't read comment 0)
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.
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 :(
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.
(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
(In reply to Taras Glek (:taras) from comment #9) > Avi we should setup an automatic test for this Bug 848358.
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.
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?
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://firstname.lastname@example.org/
(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.
(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?
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.
Tim: do you have numbers for the impact of bug 791670 on this, now that all the reflow-causing things have been fixed?
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.