This issue happens only if accelerated-compositing is enabled. The attached simple test case is to load an iframe with 'display:none', which has some animations. Although nothing is displayed when it is loaded, 50% CPU is consumed (depends on different platform). If adding a log in ImplicitAnimation::timeToNextService() of ImplicitAnimation.cpp double ImplicitAnimation::timeToNextService() { printf("[LOG]ImplicitAnimation::timeToNextService(%p)\n", this); double t = AnimationBase::timeToNextService(); ...... } Lots of logs were outputted in the console, like [LOG]ImplicitAnimation::timeToNextService(0x726e9ec8) [LOG]ImplicitAnimation::timeToNextService(0x726e9e70) [LOG]ImplicitAnimation::timeToNextService(0x726e9000) [LOG]ImplicitAnimation::timeToNextService(0x726e9058) [LOG]ImplicitAnimation::timeToNextService(0x726e9ec8) [LOG]ImplicitAnimation::timeToNextService(0x726e9e70) [LOG]ImplicitAnimation::timeToNextService(0x726e9f78) [LOG]ImplicitAnimation::timeToNextService(0x726e9f20) [LOG]ImplicitAnimation::timeToNextService(0x726e9058) [LOG]ImplicitAnimation::timeToNextService(0x726e9000) How to reproduce this issue? 1/ unzip simple_case.zip 2/ enable accelerated-compositing 3/ load unzipped tbc.html The reason is in GraphicsLayerTextureMapper::addAnimation(). This issue is the side-effect of replacing m_animationStartedTimer.startOneShot(0) by notifyChange(AnimationStarted) in GraphicsLayerTextureMapper::addAnimation(). In fact, if the current GraphicsLayerTextureMapper object is not in GraphicsLayer tree, like the iframe in the attached simple case, it's GraphicsLayerTextureMapper::commitLayerChanges() can't be triggered, so AnimationStarted event can't be dispatched into AnimationController to stop the animation timer.
Created attachment 255817 [details] the simple case to reproduce this issue.
Simon, could you verify if this issuce can be reproduced with recent Safar? Thanks!
No, I don't see any animations running in the iframe in Mac Safari.
There is no any animation displayed on screen when it is running, but it causes CPU to be busy because timer of AnimationController is continually created and destroyed. The best way is to add a log in ImplicitAnimation::timeToNextService() as my first comment, and then load the attached simple case.
The code in question has been removed from WebKit.