RenderSubtree: Early out in PaintLayer::UpdateLayerPositionAfterLayout if locked.

This patch puts an early out for cases where the layout (for position)
or paint (for pagination) is blocked by the display lock.

This takes the growing update time on the referenced bug (example
in comment 17) from ~8ms per frame to ~1ms per frame on my linux desktop.

R=chrishtr@chromium.org

Bug: 999486
Change-Id: I1c7a2a1948371c61565c079d30341c0ee4c7e8b7
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1934509Reviewed-by: Chris Harrelson <chrishtr@chromium.org>
Commit-Queue: vmpstr <vmpstr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#718776}

third_party/blink/renderer/core/paint/paint_layer.cc

@@ -344,6 +344,15 @@ void PaintLayer::UpdateLayerPositionRecursive() {
       SetNeedsCompositingInputsUpdate();
   }
 
+  // Display-locked elements always have a PaintLayer, meaning that the
+  // PaintLayer traversal won't skip locked elements. Thus, we don't have to do
+  // an ancestor check, and simply skip iterating children when this element is
+  // locked for child layout.
+  if (GetLayoutObject().LayoutBlockedByDisplayLock(
+          DisplayLockLifecycleTarget::kChildren)) {
+    return;
+  }
+
   for (PaintLayer* child = FirstChild(); child; child = child->NextSibling())
     child->UpdateLayerPositionRecursive();
 }
@@ -519,6 +528,13 @@ void PaintLayer::UpdatePaginationRecursive(bool needs_pagination_update) {
           containing_flow_thread->Layer();
   }
 
+  // If this element prevents child painting, then we can skip updating
+  // pagination info, since it won't be used anyway.
+  if (GetLayoutObject().PaintBlockedByDisplayLock(
+          DisplayLockLifecycleTarget::kChildren)) {
+    return;
+  }
+
   for (PaintLayer* child = FirstChild(); child; child = child->NextSibling())
     child->UpdatePaginationRecursive(needs_pagination_update);
 }