When determining slow viewport regions, use direct compositing reasons

Since fixed and sticky positioned elements are always composited,
this will be correct. This removes one dependency on compositing state.

Bug: 1100711

Change-Id: I310b25cff1dd7ead16e6fa4b95e12ed7a3de255b
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2280588
Commit-Queue: Chris Harrelson <chrishtr@chromium.org>
Commit-Queue: Philip Rogers <pdr@chromium.org>
Commit-Queue: Xianzhu Wang <wangxianzhu@chromium.org>
Auto-Submit: Chris Harrelson <chrishtr@chromium.org>
Reviewed-by: Philip Rogers <pdr@chromium.org>
Reviewed-by: Xianzhu Wang <wangxianzhu@chromium.org>
Cr-Commit-Position: refs/heads/master@{#786063}

third_party/blink/renderer/core/layout/layout_box_model_object.cc

@@ -1074,10 +1074,8 @@ bool LayoutBoxModelObject::IsSlowRepaintConstrainedObject() const {
     return false;
 
   // We're only smart enough to scroll viewport-constrainted objects
-  // in the compositor if they have their own backing or they paint
-  // into a grouped back (which necessarily all have the same viewport
-  // constraints).
-  return (layer->GetCompositingState() == kNotComposited);
+  // in the compositor if they are directly composited.
+  return !layer->CanBeCompositedForDirectReasons();
 }
 
 PhysicalRect LayoutBoxModelObject::ComputeStickyConstrainingRect() const {