[Webkit-unassigned] [Bug 123170] New: Keyframe animations do multiple style recalcs before starting

[bugzilla-daemon at webkit.org]

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

           Summary: Keyframe animations do multiple style recalcs before
                    starting
           Product: WebKit
           Version: 528+ (Nightly build)
          Platform: Unspecified
        OS/Version: Unspecified
            Status: UNCONFIRMED
          Severity: Normal
          Priority: P2
         Component: Animations
        AssignedTo: webkit-unassigned at lists.webkit.org
        ReportedBy: ralpht+bugs at gmail.com
                CC: dino at apple.com


I noticed on a slow ARM machine that starting a keyframe animation takes longer than starting a transition. Upon inspection it appears that:

 1. Transitions emit an animation to the compositor/GraphicsLayer in the first style recalc (a small recalc caused by the style mutation).
 2. The compositor manages to flush pending layer changes before the animation timer fires and causes other (full) style recalcs.

(1) is caused by ImplicitAnimation::animate calling AnimationBase::fireAnimationEventsIfNeeded after doing its work (instead of before like KeyframeAnimation::animate does). This causes the animation state machine to transition to AnimationStateStartWaitStyleAvailable inside the first small "mutate" style recalc. If I make KeyframeAnimation::animate call fireAnimationEventsIfNeeded at the end (and on the early returns too) then a keyframe animation will emit an animation to the compositor on the first "mutate" recalc too.

(2) is caused by ImplicitAnimation::endAnimation calling RenderLayerBacking::transitionFinished which calls GraphicsLayer::removeAnimation. On my port, this causes the layer flush timer to be enqueued, even if no animation was actually removed. This happens early (when the animation is created by the first recalc) so this timer gets serviced before any of the animation timers, which cause more slow recalcs. If I make KeyframeAnimation do something to schedule a layer flush then my animation gets started by the UIProcess before the slow recalcs.

I'll add a patch in a minute that does both (1) and (2) but I feel like it would be nice if (2) was more explicit (i.e.: we force a layer flush before doing the animation timer, or we have something more structured than posting timers so we can enforce a more efficient ordering). 

Independently I noticed that if I don't make the AnimationController perform style invals then everything still works except the animation/transition events. I'm not sure why the events need style recalcs, since the StyleResolver already knows to ask the AnimationController for computed styles on animated elements. We might have an opportunity to optimize away a lot of these full inval/recalcs!

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