Changeset 230396 in webkit


Ignore:
Timestamp:
Apr 9, 2018 3:52:43 AM (6 years ago)
Author:
Carlos Garcia Campos
Message:

Merge r229288 - Don't invalidate all children when doing insertion/deletion in presence of backward positional selectors
https://bugs.webkit.org/show_bug.cgi?id=183325
<rdar://problem/38134480>

Reviewed by Zalan Bujtas.

It is sufficient to invalidate siblings before the mutation point.

  • dom/Element.cpp:

(WebCore::checkForSiblingStyleChanges):

We already do sibling walk in the case of forwards positional rules and sibling combinators. The work
done here is insignifant compared to cost of overinvalidating.

Location:
releases/WebKitGTK/webkit-2.20/Source/WebCore
Files:
2 edited

Legend:

Unmodified
Added
Removed
  • releases/WebKitGTK/webkit-2.20/Source/WebCore/ChangeLog

    r230394 r230396  
     12018-03-05  Antti Koivisto  <antti@apple.com>
     2
     3        Don't invalidate all children when doing insertion/deletion in presence of backward positional selectors
     4        https://bugs.webkit.org/show_bug.cgi?id=183325
     5        <rdar://problem/38134480>
     6
     7        Reviewed by Zalan Bujtas.
     8
     9        It is sufficient to invalidate siblings before the mutation point.
     10
     11        * dom/Element.cpp:
     12        (WebCore::checkForSiblingStyleChanges):
     13
     14        We already do sibling walk in the case of forwards positional rules and sibling combinators. The work
     15        done here is insignifant compared to cost of overinvalidating.
     16
    1172018-03-03  Said Abou-Hallawa  <sabouhallawa@apple.com>
    218
  • releases/WebKitGTK/webkit-2.20/Source/WebCore/dom/Element.cpp

    r228770 r230396  
    20782078    // We have to invalidate everything following the insertion point in the forward case, and everything before the insertion point in the
    20792079    // backward case.
    2080     // |afterChange| is 0 in the parser callback case, so we won't do any work for the forward case if we don't have to.
    2081     // For performance reasons we just mark the parent node as changed, since we don't want to make childrenChanged O(n^2) by crawling all our kids
    2082     // here.  recalcStyle will then force a walk of the children when it sees that this has happened.
    2083     if (parent.childrenAffectedByBackwardPositionalRules() && elementBeforeChange)
    2084         parent.invalidateStyleForSubtree();
     2080    if (parent.childrenAffectedByBackwardPositionalRules()) {
     2081        for (auto* previous = elementBeforeChange; previous; previous = previous->previousElementSibling())
     2082            previous->invalidateStyleForSubtree();
     2083    }
    20852084}
    20862085
Note: See TracChangeset for help on using the changeset viewer.