Unless I've measured incorrectly (and there's a good chance), the main thread costs are approximately:

~40% update layers
 - Almost entirely deciding if we're solid color (~38.8%).
 - We do this determination by replaying *everything* into a skia::analysiscanvas.

30% RenderWidgetCompositor::UpdateLayers()
 - this is the document lifecycle costs
   - 20.2% paint
   - 6.1% style/layout
   - 2.4% paint invalidation

4.3% v8

Linke to the code that does the solid color analysis: https://code.google.com/p/chromium/codesearch#chromium/src/cc/playback/recording_source.cc&l=232

Vlad, should the solid color analysis early out? Can we update the value cheaply somehow?

https://bugs.chromium.org/p/chromium/issues/detail?id=611924 seems possibly relevant. You might want to check if that patch helps with the AnalysisCanvas time here.

@5, That is indeed relevant.

The solid color analysis when it comes to layers relies on the op count. Specifically, it only analyzes layers if the op count is 10 or less. If this value is reported incorrectly, then we'll end up playing back the whole raster source worth of information to the analysis canvas, which can be slow.

What do the numbers look like when the patch referenced in #5 is applied?

I looked at this benchmark on ChromeOS 51.0.2704.42 (trace attached).  One thing that seems worth investigating is that each FrameView::synchronizePaint triggers a LOT of calls to FrameView::layout (219 in the most expensive portion of the benchmark).

Deleted: trace_anim-dompart-trace.json.gz 3.3 MB

trace_anim-dompart-trace.json.gz 3.3 MB Download

Deleted: Screenshot 2016-05-20 at 2.21.01 PM.png 37.8 KB

	Screenshot 2016-05-20 at 2.21.01 PM.png 37.8 KB View Download

Layout within paint??? That isn't right. It should be impossible. I'll look.

Things look better after #5. (yay).

The breakdown I'm currently seeing is as follows:
* 65% main thread
  * 47% document work
    * 33% sync paint
    * 9.2% style/layout
    * 3.7% paint invalidation
    * 0.1% compositing update
  * 12.5% js
* 22.9 raster workers (split between 4 of them).
* 8.1% compositor thread
* 2.5% io thread

The compositor thread cost was surprising given that there's not much happening from a compositor pov. However, nothing jumped out as a clear culprit. Lots of calls, each not too awful individually, but expensive in aggregate.

It looks like every time we paint an SVG image, we check to see if we need to update style/layout.  SVGImage::drawInternal calls FrameView::updateAllLifecyclePhasesExceptPaint and this account for 9% of the total CPU time spent in the benchmark in my test.  Ideally we shouldn't be doing that here (isn't it a violation of the document lifecycle?).  pdr/fs - any idea if that's really necessary and if so why?

We're looking at a bunch of different things in this bechmark.  Filed issue 613362 to track this specific "SVG painting spends a lot of time doing layout" issue and assigned it to you Chris - thanks!

The reason FrameView::updateAllLifecyclePhasesExceptPaint is called where it is, is because of the FrameView::resize (and FrameView::processUrlFragment) call(s) at the beginning of the function. In turn the reason for that is the context-sensitivity of SVG image - depending on the embedding context sizes (and other things - c.f processUrlFragment) can change.

I guess the interesting bit here is if this is a no-op or not. (9% sounds like an expensive no-op...)

Let's discuss on 613662.