Unless the page uses features like touch-action we don't need event regions for plain main frame scrolling.
<rdar://problem/67900642>
Created attachment 408431 [details] patch
Created attachment 408432 [details] patch
Comment on attachment 408432 [details] patch View in context: https://bugs.webkit.org/attachment.cgi?id=408432&action=review > Source/WebCore/rendering/RenderLayerCompositor.cpp:880 > + if (scrollingCoordinator && scrollingCoordinator->hasSubscrollers() != hadSubscrollers) > + invalidateEventRegionForAllFrames(); I don't like that this triggers a second compositing update just after we've finished one, and in all frames too! This means that every page with one or more subscrollers now suffers from an extra full layer tree walk in all frames and a second compositing update.
> I don't like that this triggers a second compositing update just after we've > finished one, and in all frames too! No it doesn't. It just sets m_needsEventRegionUpdate bit in RenderLayerBacking.
Comment on attachment 408432 [details] patch View in context: https://bugs.webkit.org/attachment.cgi?id=408432&action=review > Source/WebCore/page/scrolling/ScrollingStateScrollingNode.cpp:39 > + scrollingStateTree().scrollingNodeAdded(); I wonder if ScrollingStateTree::addNode() is a better place to call this. > Source/WebCore/page/scrolling/ScrollingStateScrollingNode.cpp:80 > + scrollingStateTree().scrollingNodeRemoved(); I wonder if ScrollingStateTree::willRemoveNode() is a better place to call this. >> Source/WebCore/rendering/RenderLayerCompositor.cpp:880 >> + invalidateEventRegionForAllFrames(); > > I don't like that this triggers a second compositing update just after we've finished one, and in all frames too! > > This means that every page with one or more subscrollers now suffers from an extra full layer tree walk in all frames and a second compositing update. I see now that we'll update regions at the end of the rendering update.
> I wonder if ScrollingStateTree::addNode() is a better place to call this. > I wonder if ScrollingStateTree::willRemoveNode() is a better place to call > this. I considered it but this seemed like the most robust solution.
commit-queue failed to commit attachment 408432 [details] to WebKit repository.
Created attachment 408461 [details] patch
Committed r266846: <https://trac.webkit.org/changeset/266846> All reviewed patches have been landed. Closing bug and clearing flags on attachment 408461 [details].