WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
NEW
111617
Robohornet Pro's Resize Columns test spends 40% of its time in WebCore::AnimationController::getAnimatedStyleForRenderer
https://bugs.webkit.org/show_bug.cgi?id=111617
Summary
Robohornet Pro's Resize Columns test spends 40% of its time in WebCore::Anima...
Ali Juma
Reported
2013-03-06 12:59:12 PST
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)
Comment 1
2013-03-06 13:10:31 PST
Yeah, I've seen this before. We might be able to store a bit on RenderLayer backing to know if an animation is running.
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug