Bug 219445

Summary: Changing transforms on layer-backed elements with large subtrees can be incredibly slow
Product: WebKit Reporter: Jan Van Boghout <jan>
Component: CompositingAssignee: Nobody <webkit-unassigned>
Status: NEW ---    
Severity: Normal CC: koivisto, sabouhallawa, simon.fraser, smoley, thorton, webkit-bug-importer
Priority: P2 Keywords: InRadar
Version: Safari 13   
Hardware: All   
OS: All   
Attachments:
Description Flags
Reproduction and details
none
test case that isn't so slow as to be unusable none

Description Jan Van Boghout 2020-12-02 11:17:17 PST
Created attachment 415238 [details]
Reproduction and details

Open the attached reproduction file and note the instructions. When profiling, you'll note heavy activity in "Styles Recalculated".

Expected:
Changing a transform on a layer-backed element after it has laid out and painted is independent of the complexity of the subtree.

Actual:
There's a huge performance difference, implying the subtree is getting dirtied for no reason.
Comment 1 Smoley 2020-12-07 10:54:34 PST
Thanks for filing, I can reproduce this on Safari 13.1.3 as well as TOT 14.1
Comment 2 Radar WebKit Bug Importer 2020-12-07 10:54:44 PST
<rdar://problem/72054623>
Comment 3 Simon Fraser (smfr) 2020-12-07 11:01:11 PST
Not quite sure what's going on in the testcase, but sampling shows it spending a lot of time in:

    +                             2724 WebCore::Document::resolveStyle(WebCore::Document::ResolveStyleType)  (in WebCore) + 1243  [0x7fff3abe28db]
    +                               2724 WebCore::Document::updateRenderTree(std::__1::unique_ptr<WebCore::Style::Update const, std::__1::default_delete<WebCore::Style::Update const> >)  (in WebCore) + 180  [0x7fff3abe23a4]
    +                                 2724 WebCore::RenderTreeUpdater::commit(std::__1::unique_ptr<WebCore::Style::Update const, std::__1::default_delete<WebCore::Style::Update const> >)  (in WebCore) + 2388  [0x7fff3b67f774]
    +                                   2724 WebCore::RenderTreeUpdater::updateElementRenderer(WebCore::Element&, WebCore::Style::ElementUpdate const&)  (in WebCore) + 87  [0x7fff3b680d57]
    +                                     2723 WebCore::RenderTreeUpdater::tearDownRenderers(WebCore::Element&, WebCore::RenderTreeUpdater::TeardownType, WebCore::RenderTreeBuilder&)  (in WebCore) + 491  [0x7fff3b68267b]
    +                                     ! 2721 WebCore::RenderTreeUpdater::tearDownRenderers(WebCore::Element&, WebCore::RenderTreeUpdater::TeardownType, WebCore::RenderTreeBuilder&)::$_2::operator()(unsigned int) const  (in WebCore) + 787  [0x7fff3b682d13]
    +                                     ! : 2706 WebCore::RenderTreeBuilder::destroyAndCleanUpAnonymousWrappers(WebCore::RenderObject&)  (in WebCore) + 286  [0x7fff3b6732be]
    +                                     ! : | 2706 WebCore::RenderTreeBuilder::removeAnonymousWrappersForInlineChildrenIfNeeded(WebCore::RenderElement&)  (in WebCore) + 593,128,...  [0x7fff3b672f31,0x7fff3b672d60,...]
Comment 4 Simon Fraser (smfr) 2020-12-07 16:37:33 PST
Created attachment 415600 [details]
test case that isn't so slow as to be unusable