[Webkit-unassigned] [Bug 64851] Optimize AnimationController::updateAnimations

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Thu Jul 21 17:52:43 PDT 2011


https://bugs.webkit.org/show_bug.cgi?id=64851





--- Comment #6 from zeng huiqing <huiqing.zeng at intel.com>  2011-07-21 17:52:43 PST ---
Many thanks for helping review the patch and the good comments:)

> In general I don't like that this adds the parameter to setAnimatableStyle. Is there way the RenderObject can know if it is attached to the tree so that we don't have to pass the flag around? From a brief investigation this path is only hit when the RenderObject is not in the render tree (it shouldn't have a parent) - is this correct?


Through debugging, I found there exist another two call paths for RenderObject::setAnimatableStyle():
1)
WebKitClientImpl::DoTimeout()->ThreadTimers::sharedTimerFiredInternal()->Timer<AnimationControllerPrivate>::fired()->AnimationControllerPrivate::animationTimerFired()->AnimationControllerPrivate::updateAnimationTimer()[or AnimationControllerPrivate::fireEventsAndUpdateStyle]->Document::updateStyleIfNeeded()->Element::recalcStyle()->Node::setRenderStyle()->RenderObject::setAnimatableStyle()

2)
StyleElement::createSheet()->...->Document::styleSelectorChanged()->Element::recalcStyle()->Node::setRenderStyle()->RenderObject::setAnimatableStyle()

These two call paths both happen before "Attach", and I am sorry I am not sure whether can remove updateAnimationTimer() in these two paths when loading page w/ only transition property, so I add parameter to setAnimatableStyle().

And through profiling, we can find that the function AnimationController::updateAnimationTimer() doing in the process of "Attach" will consume a lot of time when loading page w/ transition property, especially when the page has many RenderObjects w/ transition property.

I will update the patch according to your good comments, thank you very much:).

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.



More information about the webkit-unassigned mailing list