nephele
/
haikuwebkit
1
0
Fork 0
Code Issues Releases Activity
haikuwebkit/LayoutTests/pageoverlay/overlay-remove-reinsert-vie...

100 lines
2.0 KiB
Plaintext
Raw Permalink Normal View History

Clean up how GraphicsLayer's "inWindow" state is set, and fix some issues with Page Overlays https://bugs.webkit.org/show_bug.cgi?id=167850 Reviewed by Tim Horton. Source/WebCore: RenderLayerCompositor::setIsInWindowForLayerIncludingDescendants() walked the RenderLayer tree to set the GraphicsLayer's "inWindow" state. This had the problem of skipping non-primary GraphicsLayers. We also never did this work for page overlay layers. Fix by giving GraphicsLayers a recursive function that sets the inWindow state, and call that from RenderLayerCompositor::setIsInWindow() and PageOverlayController. PageOverlayController also needs to implement tiledBackingUsageChanged so that tiled backings created dynamically get the correct in-window state. Page overlays also had some serious issues in MiniBrowser, in that they disappeared on reload, and on hide/show web view. This was because the overlay root layers were re-parented, but addChild() for each overlay's layer wasn't called. Clean up by replacing willAttachRootLayer() followed by viewOverlayRootLayer()/documentOverlayRootLayer() with single calls that set up the layers, update the inWindow state, and return the layer. Make it possible to dump tile caches in page overlay tests. Make showGraphicsLayers() always dump page overlay layers (source of much confusion). Test: pageoverlay/overlay-remove-reinsert-view.html * page/PageOverlayController.cpp: (WebCore::PageOverlayController::documentOverlayRootLayer): (WebCore::PageOverlayController::viewOverlayRootLayer): (WebCore::PageOverlayController::layerWithDocumentOverlays): (WebCore::PageOverlayController::layerWithViewOverlays): (WebCore::PageOverlayController::tiledBackingUsageChanged): (WebCore::PageOverlayController::willAttachRootLayer): Deleted. * page/PageOverlayController.h: * platform/graphics/GraphicsLayer.cpp: (WebCore::GraphicsLayer::setIsInWindowIncludingDescendants): (WebCore::dumpChildren): * platform/graphics/GraphicsLayer.h: * rendering/RenderLayerCompositor.cpp: (WebCore::RenderLayerCompositor::appendDocumentOverlayLayers): (WebCore::RenderLayerCompositor::setIsInWindow): (WebCore::RenderLayerCompositor::attachRootLayer): (WebCore::RenderLayerCompositor::rootLayerAttachmentChanged): (WebCore::RenderLayerCompositor::setIsInWindowForLayerIncludingDescendants): Deleted. * rendering/RenderLayerCompositor.h: * testing/Internals.cpp: (WebCore::toLayerTreeFlags): (WebCore::Internals::layerTreeAsText): (WebCore::Internals::pageOverlayLayerTreeAsText): * testing/Internals.h: * testing/Internals.idl: * testing/MockPageOverlayClient.cpp: (WebCore::MockPageOverlayClient::layerTreeAsText): * testing/MockPageOverlayClient.h: Tools: * DumpRenderTree/TestRunner.cpp: (TestRunner::uiScriptDidComplete): Fix an assertion that fires for non-16-bit strings. LayoutTests: * pageoverlay/overlay-large-document-expected.txt: * pageoverlay/overlay-large-document-scrolled-expected.txt: * pageoverlay/overlay-remove-reinsert-view-expected.txt: Added. * pageoverlay/overlay-remove-reinsert-view.html: Added. * platform/ios-simulator-wk2/pageoverlay/overlay-remove-reinsert-view-expected.txt: Added. * platform/mac-wk1/pageoverlay/overlay-remove-reinsert-view-expected.txt: Added. * tiled-drawing/tiled-backing-in-window-expected.txt: Canonical link: https://commits.webkit.org/184886@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@211683 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2017-02-05 19:18:16 +00:00
CONSOLE MESSAGE: MockPageOverlayClient::drawRect dirtyRect (0, 0, 785, 585)
CONSOLE MESSAGE: MockPageOverlayClient::drawRect dirtyRect (512, 512, 512, 512)
CONSOLE MESSAGE: MockPageOverlayClient::drawRect dirtyRect (0, 512, 512, 512)
CONSOLE MESSAGE: MockPageOverlayClient::drawRect dirtyRect (512, 0, 512, 512)
CONSOLE MESSAGE: MockPageOverlayClient::drawRect dirtyRect (0, 0, 512, 512)
Initial layers
View-relative:
(GraphicsLayer
(children 1
(GraphicsLayer
(anchor 0.00 0.00)
(bounds 800.00 600.00)
(drawsContent 1)
(backgroundColor #00000000)
)
)
)
Document-relative:
(GraphicsLayer
(children 1
(GraphicsLayer
(anchor 0.00 0.00)
(bounds 5008.00 5016.00)
(usingTiledLayer 1)
(drawsContent 1)
(backgroundColor #00000000)
(tile cache coverage 0, 0 1024 x 1024)
(tile size 512 x 512)
(top left tile 0, 0 tiles grid 2 x 2)
(in window 1)
)
)
)
Layers after removal
View-relative:
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. Canonical link: https://commits.webkit.org/208700@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@240940 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2019-02-04 21:16:22 +00:00
(GraphicsLayer
(children 1
(GraphicsLayer
(anchor 0.00 0.00)
(bounds 800.00 600.00)
(drawsContent 1)
(backgroundColor #00000000)
)
)
)
Clean up how GraphicsLayer's "inWindow" state is set, and fix some issues with Page Overlays https://bugs.webkit.org/show_bug.cgi?id=167850 Reviewed by Tim Horton. Source/WebCore: RenderLayerCompositor::setIsInWindowForLayerIncludingDescendants() walked the RenderLayer tree to set the GraphicsLayer's "inWindow" state. This had the problem of skipping non-primary GraphicsLayers. We also never did this work for page overlay layers. Fix by giving GraphicsLayers a recursive function that sets the inWindow state, and call that from RenderLayerCompositor::setIsInWindow() and PageOverlayController. PageOverlayController also needs to implement tiledBackingUsageChanged so that tiled backings created dynamically get the correct in-window state. Page overlays also had some serious issues in MiniBrowser, in that they disappeared on reload, and on hide/show web view. This was because the overlay root layers were re-parented, but addChild() for each overlay's layer wasn't called. Clean up by replacing willAttachRootLayer() followed by viewOverlayRootLayer()/documentOverlayRootLayer() with single calls that set up the layers, update the inWindow state, and return the layer. Make it possible to dump tile caches in page overlay tests. Make showGraphicsLayers() always dump page overlay layers (source of much confusion). Test: pageoverlay/overlay-remove-reinsert-view.html * page/PageOverlayController.cpp: (WebCore::PageOverlayController::documentOverlayRootLayer): (WebCore::PageOverlayController::viewOverlayRootLayer): (WebCore::PageOverlayController::layerWithDocumentOverlays): (WebCore::PageOverlayController::layerWithViewOverlays): (WebCore::PageOverlayController::tiledBackingUsageChanged): (WebCore::PageOverlayController::willAttachRootLayer): Deleted. * page/PageOverlayController.h: * platform/graphics/GraphicsLayer.cpp: (WebCore::GraphicsLayer::setIsInWindowIncludingDescendants): (WebCore::dumpChildren): * platform/graphics/GraphicsLayer.h: * rendering/RenderLayerCompositor.cpp: (WebCore::RenderLayerCompositor::appendDocumentOverlayLayers): (WebCore::RenderLayerCompositor::setIsInWindow): (WebCore::RenderLayerCompositor::attachRootLayer): (WebCore::RenderLayerCompositor::rootLayerAttachmentChanged): (WebCore::RenderLayerCompositor::setIsInWindowForLayerIncludingDescendants): Deleted. * rendering/RenderLayerCompositor.h: * testing/Internals.cpp: (WebCore::toLayerTreeFlags): (WebCore::Internals::layerTreeAsText): (WebCore::Internals::pageOverlayLayerTreeAsText): * testing/Internals.h: * testing/Internals.idl: * testing/MockPageOverlayClient.cpp: (WebCore::MockPageOverlayClient::layerTreeAsText): * testing/MockPageOverlayClient.h: Tools: * DumpRenderTree/TestRunner.cpp: (TestRunner::uiScriptDidComplete): Fix an assertion that fires for non-16-bit strings. LayoutTests: * pageoverlay/overlay-large-document-expected.txt: * pageoverlay/overlay-large-document-scrolled-expected.txt: * pageoverlay/overlay-remove-reinsert-view-expected.txt: Added. * pageoverlay/overlay-remove-reinsert-view.html: Added. * platform/ios-simulator-wk2/pageoverlay/overlay-remove-reinsert-view-expected.txt: Added. * platform/mac-wk1/pageoverlay/overlay-remove-reinsert-view-expected.txt: Added. * tiled-drawing/tiled-backing-in-window-expected.txt: Canonical link: https://commits.webkit.org/184886@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@211683 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2017-02-05 19:18:16 +00:00
Document-relative:
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. Canonical link: https://commits.webkit.org/208700@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@240940 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2019-02-04 21:16:22 +00:00
(GraphicsLayer
(children 1
(GraphicsLayer
(anchor 0.00 0.00)
(bounds 5008.00 5016.00)
(usingTiledLayer 1)
(drawsContent 1)
(backgroundColor #00000000)
(tile cache coverage 0, 0 1024 x 1024)
(tile size 512 x 512)
(top left tile 0, 0 tiles grid 2 x 2)
(in window 0)
)
)
)
Clean up how GraphicsLayer's "inWindow" state is set, and fix some issues with Page Overlays https://bugs.webkit.org/show_bug.cgi?id=167850 Reviewed by Tim Horton. Source/WebCore: RenderLayerCompositor::setIsInWindowForLayerIncludingDescendants() walked the RenderLayer tree to set the GraphicsLayer's "inWindow" state. This had the problem of skipping non-primary GraphicsLayers. We also never did this work for page overlay layers. Fix by giving GraphicsLayers a recursive function that sets the inWindow state, and call that from RenderLayerCompositor::setIsInWindow() and PageOverlayController. PageOverlayController also needs to implement tiledBackingUsageChanged so that tiled backings created dynamically get the correct in-window state. Page overlays also had some serious issues in MiniBrowser, in that they disappeared on reload, and on hide/show web view. This was because the overlay root layers were re-parented, but addChild() for each overlay's layer wasn't called. Clean up by replacing willAttachRootLayer() followed by viewOverlayRootLayer()/documentOverlayRootLayer() with single calls that set up the layers, update the inWindow state, and return the layer. Make it possible to dump tile caches in page overlay tests. Make showGraphicsLayers() always dump page overlay layers (source of much confusion). Test: pageoverlay/overlay-remove-reinsert-view.html * page/PageOverlayController.cpp: (WebCore::PageOverlayController::documentOverlayRootLayer): (WebCore::PageOverlayController::viewOverlayRootLayer): (WebCore::PageOverlayController::layerWithDocumentOverlays): (WebCore::PageOverlayController::layerWithViewOverlays): (WebCore::PageOverlayController::tiledBackingUsageChanged): (WebCore::PageOverlayController::willAttachRootLayer): Deleted. * page/PageOverlayController.h: * platform/graphics/GraphicsLayer.cpp: (WebCore::GraphicsLayer::setIsInWindowIncludingDescendants): (WebCore::dumpChildren): * platform/graphics/GraphicsLayer.h: * rendering/RenderLayerCompositor.cpp: (WebCore::RenderLayerCompositor::appendDocumentOverlayLayers): (WebCore::RenderLayerCompositor::setIsInWindow): (WebCore::RenderLayerCompositor::attachRootLayer): (WebCore::RenderLayerCompositor::rootLayerAttachmentChanged): (WebCore::RenderLayerCompositor::setIsInWindowForLayerIncludingDescendants): Deleted. * rendering/RenderLayerCompositor.h: * testing/Internals.cpp: (WebCore::toLayerTreeFlags): (WebCore::Internals::layerTreeAsText): (WebCore::Internals::pageOverlayLayerTreeAsText): * testing/Internals.h: * testing/Internals.idl: * testing/MockPageOverlayClient.cpp: (WebCore::MockPageOverlayClient::layerTreeAsText): * testing/MockPageOverlayClient.h: Tools: * DumpRenderTree/TestRunner.cpp: (TestRunner::uiScriptDidComplete): Fix an assertion that fires for non-16-bit strings. LayoutTests: * pageoverlay/overlay-large-document-expected.txt: * pageoverlay/overlay-large-document-scrolled-expected.txt: * pageoverlay/overlay-remove-reinsert-view-expected.txt: Added. * pageoverlay/overlay-remove-reinsert-view.html: Added. * platform/ios-simulator-wk2/pageoverlay/overlay-remove-reinsert-view-expected.txt: Added. * platform/mac-wk1/pageoverlay/overlay-remove-reinsert-view-expected.txt: Added. * tiled-drawing/tiled-backing-in-window-expected.txt: Canonical link: https://commits.webkit.org/184886@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@211683 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2017-02-05 19:18:16 +00:00
Layers after re-insertion
View-relative:
(GraphicsLayer
(children 1
(GraphicsLayer
(anchor 0.00 0.00)
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. Canonical link: https://commits.webkit.org/208700@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@240940 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2019-02-04 21:16:22 +00:00
(bounds 800.00 600.00)
Clean up how GraphicsLayer's "inWindow" state is set, and fix some issues with Page Overlays https://bugs.webkit.org/show_bug.cgi?id=167850 Reviewed by Tim Horton. Source/WebCore: RenderLayerCompositor::setIsInWindowForLayerIncludingDescendants() walked the RenderLayer tree to set the GraphicsLayer's "inWindow" state. This had the problem of skipping non-primary GraphicsLayers. We also never did this work for page overlay layers. Fix by giving GraphicsLayers a recursive function that sets the inWindow state, and call that from RenderLayerCompositor::setIsInWindow() and PageOverlayController. PageOverlayController also needs to implement tiledBackingUsageChanged so that tiled backings created dynamically get the correct in-window state. Page overlays also had some serious issues in MiniBrowser, in that they disappeared on reload, and on hide/show web view. This was because the overlay root layers were re-parented, but addChild() for each overlay's layer wasn't called. Clean up by replacing willAttachRootLayer() followed by viewOverlayRootLayer()/documentOverlayRootLayer() with single calls that set up the layers, update the inWindow state, and return the layer. Make it possible to dump tile caches in page overlay tests. Make showGraphicsLayers() always dump page overlay layers (source of much confusion). Test: pageoverlay/overlay-remove-reinsert-view.html * page/PageOverlayController.cpp: (WebCore::PageOverlayController::documentOverlayRootLayer): (WebCore::PageOverlayController::viewOverlayRootLayer): (WebCore::PageOverlayController::layerWithDocumentOverlays): (WebCore::PageOverlayController::layerWithViewOverlays): (WebCore::PageOverlayController::tiledBackingUsageChanged): (WebCore::PageOverlayController::willAttachRootLayer): Deleted. * page/PageOverlayController.h: * platform/graphics/GraphicsLayer.cpp: (WebCore::GraphicsLayer::setIsInWindowIncludingDescendants): (WebCore::dumpChildren): * platform/graphics/GraphicsLayer.h: * rendering/RenderLayerCompositor.cpp: (WebCore::RenderLayerCompositor::appendDocumentOverlayLayers): (WebCore::RenderLayerCompositor::setIsInWindow): (WebCore::RenderLayerCompositor::attachRootLayer): (WebCore::RenderLayerCompositor::rootLayerAttachmentChanged): (WebCore::RenderLayerCompositor::setIsInWindowForLayerIncludingDescendants): Deleted. * rendering/RenderLayerCompositor.h: * testing/Internals.cpp: (WebCore::toLayerTreeFlags): (WebCore::Internals::layerTreeAsText): (WebCore::Internals::pageOverlayLayerTreeAsText): * testing/Internals.h: * testing/Internals.idl: * testing/MockPageOverlayClient.cpp: (WebCore::MockPageOverlayClient::layerTreeAsText): * testing/MockPageOverlayClient.h: Tools: * DumpRenderTree/TestRunner.cpp: (TestRunner::uiScriptDidComplete): Fix an assertion that fires for non-16-bit strings. LayoutTests: * pageoverlay/overlay-large-document-expected.txt: * pageoverlay/overlay-large-document-scrolled-expected.txt: * pageoverlay/overlay-remove-reinsert-view-expected.txt: Added. * pageoverlay/overlay-remove-reinsert-view.html: Added. * platform/ios-simulator-wk2/pageoverlay/overlay-remove-reinsert-view-expected.txt: Added. * platform/mac-wk1/pageoverlay/overlay-remove-reinsert-view-expected.txt: Added. * tiled-drawing/tiled-backing-in-window-expected.txt: Canonical link: https://commits.webkit.org/184886@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@211683 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2017-02-05 19:18:16 +00:00
(drawsContent 1)
(backgroundColor #00000000)
)
)
)
Document-relative:
(GraphicsLayer
(children 1
(GraphicsLayer
(anchor 0.00 0.00)
(bounds 5008.00 5016.00)
(usingTiledLayer 1)
(drawsContent 1)
(backgroundColor #00000000)
(tile cache coverage 0, 0 1024 x 1024)
(tile size 512 x 512)
(top left tile 0, 0 tiles grid 2 x 2)
(in window 1)
)
)
)