A couple of questions to help us route this better:
1. Do you have any flags enabled, in particular use-google-local-ntp?
2. Can you explain the difference you see between the doodle on google.com and on the NTP? Is it just the animation of the play button?

Thanks!

1) no flag enabled.
2) yes, only difference is that play button animates on www.google.com, while it doesn't on NTP.

I also tested on ToT and had same behavior.
I also tested normal NTP w/o doogle and this didn't happen.

Can you point to some info about how the trace was trace captured? 

Does the draw & swap only occur on CrOS, and does it it impact perf?

Here is what I did
1) open two tabs, chrome://tracing and NTP
2) start tracing
3) switch to NTP, waited for a while
4) switch back to chrome://traching

I just noticed this while looking to animation jank issue, and want to know if this is expected, or something that we can fix or improve.

I'm looking into more generic way to improve animation (by suspending frame updates during animation), so this won't be an issue for perf (hopefully).

It can potentially impact battery performance though.

Thanks for the very detailed response. 

This seems specific to this doodle. Adding jshneier@ to comment on whether it's expected.

The doodle doesn't show any animation in its initial state on NTP, but it does start its render loop immediately instead of waiting for the first click.  Apologies for that, we wrote a new implementation of our main render loop for this one and didn't think to optimize this case.  We'll make a note for future doodles.

We do stop the render loop when the tab is not visible, however (per the page visibility api).

#c6 & #c7: Thanks for the explanation.

Given that this issue is specific to the Halloween Doodle (which has limited time remaining), and impact is pretty minimal, I'm going to mark this bug as WontFix.

Thanks for your report oshima@!

sg, thanks!