Google login page burns CPU running a no-op animation |
||||
Issue descriptionGoogle Chrome 54.0.2815.0 (Official Build) canary (64-bit) Revision b04cd370dcb7e737fe32d3c8a0f12daa59fa85f8-refs/heads/master@{#408889} OS Mac OS X What steps will reproduce the problem? (1) Go to https://hire.lever.co/auth/login?continue=%2F (2) Click "Sign in with Google" (3) Enter any google account email (gmail, etc.) (4) Open tracing and see an infinite number of frames being pumped. If you turn on repaint rects you'll see there's nothing flashing, so we're not repainting, but we *are* pumping frames at 60fps as fast as possible burning your battery. The inspector tells me there's 4 elements going through a style recalc every frame. The frame is being scheduled here: content::RenderWidgetCompositor::setNeedsBeginFrame() blink::ScrollableArea::scheduleAnimation() blink::AnimationTimeline::scheduleNextService() blink::PaintLayerCompositor::updateIfNeededRecursiveInternal() blink::PaintLayerCompositor::updateIfNeededRecursive() blink::FrameView::updateLifecyclePhasesInternal(blink::DocumentLifecycle::LifecycleState) blink::PageAnimator::updateAllLifecyclePhases(blink::LocalFrame&) blink::WebViewImpl::updateAllLifecyclePhases() cc::ProxyMain::BeginMainFrame(...)
,
Aug 2 2016
There are four infinite animations running on that page, you can see them if you load the page with the animation inspector open. These are transform animations so I suppose the bug here is why is the main thread performing style recalc every frame?
,
Aug 2 2016
Why are frames being generated at all? Nothing on the page is changing.
,
Aug 2 2016
If you mouse over the elements being animated you can see them flying across the head of the page. I presume they're being occluded by elements in front of them, it's hard to tell exactly. I imagine there'd need to be logic in the compositor to ensure animation frames on elements that remain occluded don't trigger a frame render.
,
Aug 2 2016
*mouse over the elements in the DevTools DOM tree
,
Aug 2 2016
,
Aug 4 2016
The main thread running all those frames for a compositor animation seems like a bug not a feature? Unfortunately Gaia is serving me a different login page now so I can't repro :/
,
Aug 4 2016
I looked a little closer and saw that they're not composited animations due to the use of percentages.
@keyframes primary-indeterminate-translate {
0% {
-webkit-transform: translateX(-145.166611%);
transform: translateX(-145.166611%);
}
20% {
-webkit-animation-timing-function: cubic-bezier(.5,0,.701732,.495819);
animation-timing-function: cubic-bezier(.5,0,.701732,.495819);
-webkit-transform: translateX(-145.166611%);
transform: translateX(-145.166611%);
}
59.15% {
-webkit-animation-timing-function: cubic-bezier(.302435,.381352,.55,.956352);
animation-timing-function: cubic-bezier(.302435,.381352,.55,.956352);
-webkit-transform: translateX(-61.495191%);
transform: translateX(-61.495191%);
}
100% {
-webkit-transform: translateX(55.444446%);
transform: translateX(55.444446%);
}
}
,
Aug 4 2016
google3 has: @mixin animation(primary-indeterminate-translate 2s infinite linear); could you file a bug against the login page that they should be setting it to display none?
,
Aug 5 2016
Filed b/30681399.
,
Aug 8 2016
Closing as WontFix due to these actually being main thread animations rather than composited animations. See (internal) bug in #10 for further developments. |
||||
►
Sign in to add a comment |
||||
Comment 1 by esprehn@chromium.org
, Aug 1 2016