Heurstically use fragments in |MoveToIncludingCulledInline|
crbug.com/1111154 discovered that |getBoundingClientRect()| for culled inline has regressed a lot in LayoutNG. r793989 crrev.com/c/2332083 fixed this by traversing |LayoutObject| tree instead of fragments. This change, however, regressed a hit-testing performance case previously raised at crbug.com/1008523, because hit- testing uses |MoveToIncludingCulledInline| for every leaf, by limiting the search range to the containing line. This can easily lead to thousands of |MoveToIncludingCulledInline| for one hit-test request. This patch changes the function to revert the change if the search range is limited. In this case, most of |LayoutObject| descendants may not be in the search range, and that the searching fragments can be faster than searching |LayoutObject| descendants. Case A Case B Before r793989: 19 420 ToT: 2,556 9,064 This CL: 16 403 Numbers in milliseconds Case A: test attached to crbug/1008523 Case B: culled-inline-hittest.html in this CL Note, the design to call |MoveToIncludingCulledInline| so many times is questionable, but this CL does not try to change it to reduce the risk of regressions. Bug: 1127976, 1008523 Change-Id: Id21dd07cba0d0746b779b913ae9f180a77e23c46 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2409734Reviewed-by:Ian Kilpatrick <ikilpatrick@chromium.org> Commit-Queue: Koji Ishii <kojii@chromium.org> Cr-Commit-Position: refs/heads/master@{#807114}
Showing
Please register or sign in to comment