Bug 221344 – Optimize Styleable::elementWasRemoved()

• Component: Animations
• Status: NEW

[Simon Fraser (smfr)]

AnimationTimeline::elementWasRemoved() shows up as hot in Speedometer since Element::removedFromAncestor() is called a lot. I see removals with both idle and active animations (color transitions).

      WebCore::Element::removedFromAncestor(WebCore::Node::RemovalType, WebCore::ContainerNode&)
       WebCore::AnimationTimeline::elementWasRemoved(WebCore::Styleable const&)
        WebCore::DeclarativeAnimation::cancel(WebCore::WebAnimation::Silently)
         WebCore::WebAnimation::cancel(WebCore::WebAnimation::Silently)
         WebCore::AnimationEffect::getBasicTiming(WTF::Optional<WTF::Seconds>) const
          WebCore::AnimationEffect::getBasicTiming(WTF::Optional<WTF::Seconds>) const::$_0::operator()() const
           WebCore::WebAnimation::currentTime(WTF::Optional<WTF::Seconds>) const
            WebCore::WebAnimation::currentTime(WebCore::WebAnimation::RespectHoldTime, WTF::Optional<WTF::Seconds>) const
            WebCore::DocumentTimeline::currentTime()
         WTF::fastMalloc(unsigned long)
          bmalloc::api::malloc(unsigned long, bmalloc::HeapKind)
           bmalloc::Cache::allocate(bmalloc::HeapKind, unsigned long)
         WebCore::WebAnimation::effect() const
        WebCore::DeclarativeAnimation::invalidateDOMEvents(WTF::Seconds)

[Antoine Quint]

We should look into caching basic and computed timing, but we'll have to be careful here because their output can vary when any timing property is changed, not just the timeline time. However, in the process of an animation simply running after initial setup without any change made via CSS or the JS API, which should be the vast majority of cases, we might be able to see some gains here.

I also think that kind of optimization would show immediate regressions in WPT tests in case something went wrong.

[Radar WebKit Bug Importer]

<rdar://problem/74196202>