Rendering the page and drawing thumbnails hurts esp. while the tabopen animation is running. Even with the newtab preloader just drawing the thumbnail causes enough jank to not show an animation at all on rMBPs. Delaying showing thumbnails until after the tabopen animation yields good results on my machine so far. Just loading the page has some impact still so the BrowserNewTabPreloader is still quite useful and it might be even more when testing on a slower machine.

Alex, do you want to take this as well?

I've already ran the talos tests for a patch for this bug. I'll make a chart with the results and we'll have to wait for some ux reviews because current behavior is changed pretty much. This also means that the bug can be wontfix.

Short update to this bug: I don't know if there were other discussions after, but we concluded that it would be ok to have this feature. The newtab window should fade in after the animation. This means that we can set the newtab window to display: none at the beginning of the animation and set it later to display: -moz-box or block; opacity: 0. When the animation ends, let it transition to opacity: 1. Here is a recording of a similar behavior: https://www.youtube.com/watch?v=HMauqYCVMqg The recording features a 300 ms fade in ease-in-out transition. The problem in the recording is that the newtab window has opacity: 0 at the beginning and it never has display: none, so the layout is rendered and the newtab animation is not that smooth (but it can be probably solved with what I've said in the first paragraph). The recording is still relevant for the fade in part. Tim, what are your thoughts about this?

Not quite sure what's the status of this and whether we'd still want it. We would need to check the results of bug 1077652 to find out if hiding thumbnails and possibly flickering is worth the possible perf win. Sorry, it took me so long to get back.