Hi Team,

I came across this potential optimization but I am not 100% sure, it would be applicable as is in Safari / WebKit but I notice same function and code, so I thought to raise it.

Blink Commit: https://chromium.googlesource.com/chromium/blink/+/d16821075540cf768b4bb812d4d518f70b12a413

"While walking the frame tree during layout, at every node of the walk, we'd
walk down the frame tree again to update the "can blit on scroll" bit.  At each
node of that recursive walk, we'd walk all the way back to the root to check
for being unable to blit-on-scroll in our parent frame.

This CL remove the eager computation of this state and instead just computes it
on demand when we're about to scroll. Computing the information on demand is
fast, we just need to walk up to the root of the frame tree.

The N^3 algorithm was added by Simon Fraser in
http://trac.webkit.org/changeset/71194"

WebKit Source: https://searchfox.org/wubkat/rev/aa809c03fded1f6f0c99d562ee397ee2f472fee9/Source/WebCore/page/LocalFrameView.cpp#418 , https://searchfox.org/wubkat/rev/aa809c03fded1f6f0c99d562ee397ee2f472fee9/Source/WebCore/page/LocalFrameView.cpp#1458 & https://searchfox.org/wubkat/rev/aa809c03fded1f6f0c99d562ee397ee2f472fee9/Source/WebCore/platform/ScrollView.h#167 etc.

Just wanted to raise to see, if it is worthwhile fix or in another shape or form to improve performance.

Thanks!