Tested in chrome # 56.0.2924.87 stable #57.0.2987.98 and Canary #59.0.3042.0 on Mac 10.12.3 and not able to reproduce the issue.Please find the screen cast for your reference.

@ lepinski: Could you please let me know if i have missed anything and if possible,Please create new profile without extensions and apps.Re-check once in latest stable #57.0.2987.98/Canary #59.0.3042.0 and let us know the observations of the issue which would help us to triage the issue further.

Thanks in Advance.

Deleted: 700176.mp4 3.3 MB

	700176.mp4 3.3 MB View Download

Hey, thanks for the reply here. 

I was doing my best to anonymize our data and come up with a reproduction case that still causes this issue, but it looks like I didn't do a great job at that. That being said, I've just fired up Chrome with the --disable-extensions flag (that should give me a clean run, right?) and verified that I'm up to date (57.0.2987.98) and can still reproduce this on our non-anonymized version of this page.

I've attached screenshots of my chrome setup (chrome-version.png) and the task manager (task-manager.png).

When I get some free time, I'll have another go at reproducing this issue independent of our specific app/data.

Deleted: chrome-version.png 225 KB

	chrome-version.png 225 KB View Download

Deleted: task-manager.png 118 KB

	task-manager.png 118 KB View Download

Thank you for providing more feedback. Adding requester "rbasuvula@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Unable to reproduce the issue in MacBook Pro (Retina, 15-inch, Mid 2014), 10.12.3 using chrome reported version #56.0.2924.87, chrome stable #57.0.2987.98 and latest canary #59.0.3042.0.

Steps followed to reproduce the issue are as follows:
-----------
1. Loaded the website: http://chrome-cpu-bug-demo.s3-website-us-east-1.amazonaws.com/index.html
2. Opened the task manager and observed that chrome rendered the page and CPU usage drop ped back down as expected. The CPU usage stayed below 80% and dropped down till 60%.

Attaching screen cast for reference.

Thanks...!!

Deleted: 700176.mp4 2.3 MB

	700176.mp4 2.3 MB View Download

lepinski@ could you please respond to the comment #5

Hey @kkaluri, @krajshree  -- please see comment #3 from me. As I've said, it looks like my reproduction example isn't reliably reproducing this, so I'm trying to put together another example that will reliably reproduce the issue. I can reproduce it reliably with a non-anonymized page, but that's not something I can put up online for testing.

Thank you for providing more feedback. Adding requester "krajshree@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Adding Needs-Feedback back to page. @lepinski: sheriffbot automatically removes Needs-Feedback when you reply, because it isn't smart enough to parse the content of your message :)

I've put together a second reproduction page, which can be found here: https://s3.amazonaws.com/chrome-cpu-bug-demo/second-try/index.html

You'll want to click the "Click here to freeze chrome" link at the top of the page to cause the bug.

I've also made a screencast of the bug in action, attached below.

Deleted: crbug-700176-screencast.mp4 2.8 MB

	crbug-700176-screencast.mp4 2.8 MB View Download

Thank you for providing more feedback. Adding requester "shans@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Confirmed that the animation is a composited animation. The blink main thread is idle during the animation. See attached trace.

Deleted: trace_testing123.json.gz 3.6 MB

trace_testing123.json.gz 3.6 MB Download

Here's what I see:

- There's constant mainframe + compositorframe happening.

- BeginMainFrame is taking 51.253 ms which is ofc many vsyncs long.
- I don't see any paint flashing, so no main thread invalidations.
- 50% of BeginMainFrame is in WebViewImpl::updateAllLifecyclePhases which spends most of its time in PaintLayerCompositor::updateIfNeededRecursive
- The other 50% of BeginMainFrame is in LayerTreeHostInProcess::DoUpdateLayers which spends most of its time in PictureLayer::Update for *5072* layers (!!!)

- On the compositor thread, most time is in LayerTreeHostImpl::PrepareToDraw with 38.751 ms per frame. More than half of its time is in LayerTreeImpl::UpdateDrawProperties::UpdateTiles (17.791ms).
- TileManager::PrepareTiles also takes 15.264ms
- And TileManager::TileManager::IsReadyToActivate takes 9.013ms

So... having 5000 composited layers seems bad. I don't know that this is even a scene we intend to support.

Oops => chrishtr. Do you have any thoughts? Is this a case to optimize for?

Also I wonder if we're promoting 5000 things that we shouldn't be?

Summary: SPv2 will be able to solve this case by not painting the content
at all, and hence not creating composited layers for it. Instead the animation
will be forced to be main-thread (but not incur painting/raster).

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/8951c6c53fdbf06bd999541965c86da70a7999ca

commit 8951c6c53fdbf06bd999541965c86da70a7999ca
Author: chrishtr <chrishtr@chromium.org>
Date: Wed Mar 22 21:11:25 2017

[SPv2] Don't paint invisible PaintLayers with transform animations.

Only an effect animation can cause the PaintLayer to become visible via compositor
thread updates.

BUG= 700176 , 692310 

Review-Url: https://codereview.chromium.org/2770763002
Cr-Commit-Position: refs/heads/master@{#458875}

[modify] https://crrev.com/8951c6c53fdbf06bd999541965c86da70a7999ca/third_party/WebKit/Source/core/paint/PaintLayerPainter.cpp
[modify] https://crrev.com/8951c6c53fdbf06bd999541965c86da70a7999ca/third_party/WebKit/Source/core/paint/PaintLayerPainter.h
[modify] https://crrev.com/8951c6c53fdbf06bd999541965c86da70a7999ca/third_party/WebKit/Source/core/paint/PaintLayerPainterTest.cpp

This bug should "just work" with our current SPv2 design given the commit
in comment 17. Sending this bug to wkorman to see it through and check results
w/SPv2 launch.

Also note that a visibility: hidden subtree will also not paint at all
in SPv2 mode already, and hence get no composited layers. The above
patch relates to opacity: 0.