Bug 111617
| Summary: | Robohornet Pro's Resize Columns test spends 40% of its time in WebCore::AnimationController::getAnimatedStyleForRenderer | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Ali Juma <ajuma> |
| Component: | Layout and Rendering | Assignee: | Nobody <webkit-unassigned> |
| Status: | NEW | ||
| Severity: | Normal | CC: | eric, jamesr, simon.fraser, vollick |
| Priority: | P2 | ||
| Version: | 528+ (Nightly build) | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| URL: | http://ie.microsoft.com/testdrive/performance/robohornetpro/ | ||
| Bug Depends on: | |||
| Bug Blocks: | 98798 | ||
Ali Juma
Robohornet Pro's Resize Columns test (which involves repeatedly forcing layout by calling offsetTop) spends 40% of its time in WebCore::AnimationController::getAnimatedStyleForRenderer (this also accounts for about 18% of the time for the entire set of Robhornet Pro tests); 2/3 of this is spent in PropertyWrapperAcceleratedTransform::blend. This is on the Mac port.
A call to getAnimatedStyleForRenderer is made in RenderLayer::currentTransform only when we're running an accelerated transform. As an interesting consequence, disabling accelerated animations (by skipping the calls to addAnimation in RenderLayerBacking::startAnimation) significantly reduces the total time for Robohornet Pro on the Mac port (on my machine, it takes about 5.8 s with accelerated animations, and about 4.4 s with non-accelerated animations), though the animations of course get choppy.
For the same reason, the chromium port hits a 16% regression in Robohornet Pro (e.g. http://crbug.com/178419) when it accelerates all animations (instead of the present state, where the chromium port only accelerates animations that are added to GraphicsLayers already in the layer tree).
| Attachments | ||
|---|---|---|
| Add attachment proposed patch, testcase, etc. |
Simon Fraser (smfr)
Yeah, I've seen this before. We might be able to store a bit on RenderLayer backing to know if an animation is running.