PageOverlayController's layers should be created lazily
authorsimon.fraser@apple.com <simon.fraser@apple.com@268f45cc-cd09-0410-ab3c-d52691b4dbfc>
Mon, 4 Feb 2019 21:16:22 +0000 (21:16 +0000)
committersimon.fraser@apple.com <simon.fraser@apple.com@268f45cc-cd09-0410-ab3c-d52691b4dbfc>
Mon, 4 Feb 2019 21:16:22 +0000 (21:16 +0000)
commit973eb5bd27c26ef92777ccb4e47c6ff0cb393ba2
treeec94ed903ddad69fb0f52a5faf5e5684c40f19a2
parent115e91f66411affee9e4d471eb7a6ea02d32c052
PageOverlayController's layers should be created lazily
https://bugs.webkit.org/show_bug.cgi?id=194199
Source/WebCore:

Reviewed by Tim Horton.

Expose PageOverlayController::hasDocumentOverlays() and hasViewOverlays()
and use them to only parent the overlay-hosting layers when necessary.

For document overlays, RenderLayerCompositor::appendDocumentOverlayLayers() can
simply do nothing if there are none. Updates are triggered via Page::installedPageOverlaysChanged(),
which calls FrameView::setNeedsCompositingConfigurationUpdate() to trigger the root layer
compositing updates that parents the layerWithDocumentOverlays().

View overlays are added to the layer tree via the DrawingArea. When we go between having
none and some view overlays, Page::installedPageOverlaysChanged() calls attachViewOverlayGraphicsLayer()
on the ChromeClient, and the DrawingArea responds by calling updateRootLayers() and scheduling a
compositing flush (this has to be done manually because view overlay layers are outside the
subtree managed by RenderLayerCompositor).

Now that GraphicsLayers are ref-counted, we can let the DrawingArea simply retain its m_viewOverlayRootLayer;
there is no need for RenderLayerCompositor::attachRootLayer()/detachRootLayer() to do anything with view
overlay layers. This implies that a page can navigate (new FrameView) and view overlays will persist, without
having to be manually removed and re-added. We can also remove the Frame argument to attachViewOverlayGraphicsLayer().

* loader/EmptyClients.h:
* page/ChromeClient.h:
* page/FrameView.cpp:
(WebCore::FrameView::setNeedsCompositingConfigurationUpdate): These functions need to schedule a compositing flush
because there may be nothing else that does.
(WebCore::FrameView::setNeedsCompositingGeometryUpdate):
* page/Page.cpp:
(WebCore::Page::installedPageOverlaysChanged):
* page/Page.h:
* page/PageOverlayController.cpp:
(WebCore::PageOverlayController::hasDocumentOverlays const):
(WebCore::PageOverlayController::hasViewOverlays const):
(WebCore::PageOverlayController::attachViewOverlayLayers): PageOverlayController has the Page so it
might as well be the one to call through the ChromeClient.
(WebCore::PageOverlayController::detachViewOverlayLayers):
(WebCore::PageOverlayController::installPageOverlay):
(WebCore::PageOverlayController::uninstallPageOverlay):
* page/PageOverlayController.h:
* rendering/RenderLayerCompositor.cpp:
(WebCore::RenderLayerCompositor::updateCompositingLayers): isFullUpdate is always true; remove it.
(WebCore::RenderLayerCompositor::appendDocumentOverlayLayers):
(WebCore::RenderLayerCompositor::attachRootLayer):
(WebCore::RenderLayerCompositor::detachRootLayer):

Source/WebKit:

rdar://problem/46571593

Reviewed by Tim Horton.

Expose PageOverlayController::hasDocumentOverlays() and hasViewOverlays()
and use them to only parent the overlay-hosting layers when necessary.

For document overlays, RenderLayerCompositor::appendDocumentOverlayLayers() can
simply do nothing if there are none. Updates are triggered via Page::installedPageOverlaysChanged(),
which calls FrameView::setNeedsCompositingConfigurationUpdate() to trigger the root layer
compositing updates that parents the layerWithDocumentOverlays().

View overlays are added to the layer tree via the DrawingArea. When we go between having
none and some view overlays, Page::installedPageOverlaysChanged() calls attachViewOverlayGraphicsLayer()
on the ChromeClient, and the DrawingArea responds by calling updateRootLayers() and scheduling a
compositing flush (this has to be done manually because view overlay layers are outside the
subtree managed by RenderLayerCompositor).

Now that GraphicsLayers are ref-counted, we can let the DrawingArea simply retain its m_viewOverlayRootLayer;
there is no need for RenderLayerCompositor::attachRootLayer()/detachRootLayer() to do anything with view
overlay layers. This implies that a page can navigate (new FrameView) and view overlays will persist, without
having to be manually removed and re-added. We can also remove the Frame argument to attachViewOverlayGraphicsLayer().

* WebProcess/WebCoreSupport/WebChromeClient.cpp:
(WebKit::WebChromeClient::attachViewOverlayGraphicsLayer):
* WebProcess/WebCoreSupport/WebChromeClient.h:
* WebProcess/WebPage/AcceleratedDrawingArea.cpp:
(WebKit::AcceleratedDrawingArea::attachViewOverlayGraphicsLayer):
* WebProcess/WebPage/AcceleratedDrawingArea.h:
* WebProcess/WebPage/DrawingArea.h:
(WebKit::DrawingArea::attachViewOverlayGraphicsLayer):
* WebProcess/WebPage/RemoteLayerTree/RemoteLayerTreeDrawingArea.h:
* WebProcess/WebPage/RemoteLayerTree/RemoteLayerTreeDrawingArea.mm:
(WebKit::RemoteLayerTreeDrawingArea::attachViewOverlayGraphicsLayer):
* WebProcess/WebPage/mac/TiledCoreAnimationDrawingArea.h:
* WebProcess/WebPage/mac/TiledCoreAnimationDrawingArea.mm:
(WebKit::TiledCoreAnimationDrawingArea::attachViewOverlayGraphicsLayer):
(WebKit::TiledCoreAnimationDrawingArea::mainFrameContentSizeChanged):

Source/WebKitLegacy/mac:

rdar://problem/46571593

Reviewed by Tim Horton.

* WebCoreSupport/WebChromeClient.h:
* WebCoreSupport/WebChromeClient.mm:
(WebChromeClient::attachViewOverlayGraphicsLayer):

Source/WebKitLegacy/win:

rdar://problem/46571593

Reviewed by Tim Horton.

Expose PageOverlayController::hasDocumentOverlays() and hasViewOverlays()
and use them to only parent the overlay-hosting layers when necessary.

For document overlays, RenderLayerCompositor::appendDocumentOverlayLayers() can
simply do nothing if there are none. Updates are triggered via Page::installedPageOverlaysChanged(),
which calls FrameView::setNeedsCompositingConfigurationUpdate() to trigger the root layer
compositing updates that parents the layerWithDocumentOverlays().

View overlays are added to the layer tree via the DrawingArea. When we go between having
none and some view overlays, Page::installedPageOverlaysChanged() calls attachViewOverlayGraphicsLayer()
on the ChromeClient, and the DrawingArea responds by calling updateRootLayers() and scheduling a
compositing flush (this has to be done manually because view overlay layers are outside the
subtree managed by RenderLayerCompositor).

Now that GraphicsLayers are ref-counted, we can let the DrawingArea simply retain its m_viewOverlayRootLayer;
there is no need for RenderLayerCompositor::attachRootLayer()/detachRootLayer() to do anything with view
overlay layers. This implies that a page can navigate (new FrameView) and view overlays will persist, without
having to be manually removed and re-added. We can also remove the Frame argument to attachViewOverlayGraphicsLayer().

* WebCoreSupport/WebChromeClient.cpp:
(WebChromeClient::attachViewOverlayGraphicsLayer):
* WebCoreSupport/WebChromeClient.h:

LayoutTests:

rdar://problem/46571593

Reviewed by Tim Horton.

* pageoverlay/overlay-remove-reinsert-view-expected.txt: We no longer unparent the overlays
on view removal, so new results.
* platform/ios-wk2/TestExpectations: Unskip some iOS tests.
* platform/ios-wk2/pageoverlay/overlay-installation-expected.txt: Added.
* platform/ios-wk2/pageoverlay/overlay-large-document-expected.txt: Added.
* platform/ios-wk2/pageoverlay/overlay-large-document-scrolled-expected.txt: Added.
* platform/ios/TestExpectations: Unskip some iOS tests.

git-svn-id: https://svn.webkit.org/repository/webkit/trunk@240940 268f45cc-cd09-0410-ab3c-d52691b4dbfc
33 files changed:
LayoutTests/ChangeLog
LayoutTests/pageoverlay/overlay-remove-reinsert-view-expected.txt
LayoutTests/platform/ios-wk2/TestExpectations
LayoutTests/platform/ios-wk2/pageoverlay/overlay-installation-expected.txt [new file with mode: 0644]
LayoutTests/platform/ios-wk2/pageoverlay/overlay-large-document-expected.txt [new file with mode: 0644]
LayoutTests/platform/ios-wk2/pageoverlay/overlay-large-document-scrolled-expected.txt [new file with mode: 0644]
LayoutTests/platform/ios/TestExpectations
Source/WebCore/ChangeLog
Source/WebCore/loader/EmptyClients.h
Source/WebCore/page/ChromeClient.h
Source/WebCore/page/FrameView.cpp
Source/WebCore/page/Page.cpp
Source/WebCore/page/Page.h
Source/WebCore/page/PageOverlayController.cpp
Source/WebCore/page/PageOverlayController.h
Source/WebCore/rendering/RenderLayerCompositor.cpp
Source/WebKit/ChangeLog
Source/WebKit/WebProcess/WebCoreSupport/WebChromeClient.cpp
Source/WebKit/WebProcess/WebCoreSupport/WebChromeClient.h
Source/WebKit/WebProcess/WebPage/AcceleratedDrawingArea.cpp
Source/WebKit/WebProcess/WebPage/AcceleratedDrawingArea.h
Source/WebKit/WebProcess/WebPage/DrawingArea.h
Source/WebKit/WebProcess/WebPage/RemoteLayerTree/RemoteLayerTreeDrawingArea.h
Source/WebKit/WebProcess/WebPage/RemoteLayerTree/RemoteLayerTreeDrawingArea.mm
Source/WebKit/WebProcess/WebPage/WebPage.cpp
Source/WebKit/WebProcess/WebPage/mac/TiledCoreAnimationDrawingArea.h
Source/WebKit/WebProcess/WebPage/mac/TiledCoreAnimationDrawingArea.mm
Source/WebKitLegacy/mac/ChangeLog
Source/WebKitLegacy/mac/WebCoreSupport/WebChromeClient.h
Source/WebKitLegacy/mac/WebCoreSupport/WebChromeClient.mm
Source/WebKitLegacy/win/ChangeLog
Source/WebKitLegacy/win/WebCoreSupport/WebChromeClient.cpp
Source/WebKitLegacy/win/WebCoreSupport/WebChromeClient.h