[UnifiedPDF] There's a tile flicker after resizing has finished#34010
[UnifiedPDF] There's a tile flicker after resizing has finished#34010aprotyas wants to merge 1 commit intoWebKit:mainfrom
Conversation
|
EWS run on previous version of this PR (hash a8c3b63) Details |
There was a problem hiding this comment.
All of this should get rolled into TileController::tileGrid()
There was a problem hiding this comment.
i.e. m_asyncTileConfigurationChangeData ? *m_asyncTileConfigurationChangeData->pendingTileGrid : tileGrid();
Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.mm
Outdated
Show resolved
Hide resolved
Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/PDFDiscretePresentationController.mm
Outdated
Show resolved
Hide resolved
a8c3b63 to
9ec3d16
Compare
|
EWS run on previous version of this PR (hash 9ec3d16) Details |
9ec3d16 to
539e1aa
Compare
|
EWS run on previous version of this PR (hash 539e1aa) Details |
There was a problem hiding this comment.
Does this really need its own file?
There was a problem hiding this comment.
It does not, yeah, I just followed precedence set by some other identifier types. I'll probably roll this all into TileGridTypes.h eventually.
There was a problem hiding this comment.
Maybe initiateTileConfigurationChange?
There was a problem hiding this comment.
What is newGrid if DidCancelTileConfigurationChange is Yes?
There was a problem hiding this comment.
newGrid is unnecessary data if DidCancelTileConfigurationChange::Yes. I'm rolling this together into an optional argument.
There was a problem hiding this comment.
I would call this completeTileConfigurationChange or commitTileConfigurationChange. It should probably pass the identifier back, and that can be used to identify the old and new grids?
There was a problem hiding this comment.
The way I've structured the flow now, we need to know the old/new grids before commitTileConfigurationChange is called (since this would be the last step that actually does the grid swap).
So I'm renaming the method, to abstract away from the tile grid swap mechanics, but I'm keeping the signature void(TileGridIdentifier, TileGridIdentifier) for now.
There was a problem hiding this comment.
Why not DidCancelTileConfigurationChange::Yes unconditionally?
There was a problem hiding this comment.
Yeah, my comment is wrong. I was thinking of unconditionally DidCancelTileConfigurationChange::Yes here.
There was a problem hiding this comment.
I'm not convinced that we should tell the client about the new grid yet, but maybe we should before we start asking it to prepare tiles for it?
There was a problem hiding this comment.
Hmm, we're in an ambiguous situation now; maybe the callers need the rect in the existing grid (if we allow it to remain "live"). Another option is to explicitly specify that the old grid becomes a zombie and won't continue repainting.
There was a problem hiding this comment.
I would say that the client should not get a prepareContentForTile and a willRepaintTile for initial tile creation. But if prepareContentForTile was issued and then state changed, a willRepaintTile could be issued.
There was a problem hiding this comment.
Why isn't this kicking off PDF buffer generation?
|
EWS run on previous version of this PR (hash 722b711) Details |
There was a problem hiding this comment.
This seems potentially problematic.
If we're pinch zooming the PDF, and new scales are arriving to the main thread continuously at a rate faster than the plugin can paint them, won't this just cancel all of the paints?
I think that'd mean you'd just have the initial tiles displayed the whole tile (stretched to the new scale), while we keep doing lots of painting work and not displaying it.
If anything else inside the plugin is changing rendering at the same time (like an animation or something), then those changes wouldn't get displayed until you stopped pinch zooming.
It seems like we should probably suppress scale changes from reaching the plugin/tilecontroller if an existing configuration change is in progress. We'd then need to wait for the commit, the following rendering update (which is where the committed new tile grid gets serialised into a RemoteLayerTreeTransaction), and then schedule yet another rendering update. At that point we can pick up the new scale, and initiate a new configuration change.
There was a problem hiding this comment.
Am I right in saying that the GraphicsLayers for the individual tiles will be parented to the controller's GraphicsLayer from both the new and old grid simultaneously?
Is that the behaviour we want? I guess the new tiles can asynchronously change from blank to having content and cover the old tiles, and ordering hopefully means they're on top.
There was a problem hiding this comment.
This might fall into the category of 'too annoying at this point', but could it make sense to have the old tile grid be the one that's stored in a new variable, and the 'pending' grid be the primary tileGrid?
It seems like most operations want to operate on the pending one, we just want to keep the old one around so that it doesn't remove the tiles.
|
EWS run on previous version of this PR (hash a9b790d) Details |
|
EWS run on previous version of this PR (hash a284210) Details |
|
EWS run on previous version of this PR (hash def7eea) Details |
https://bugs.webkit.org/show_bug.cgi?id=270041 rdar://123566595 Reviewed by NOBODY (OOPS!). WIP. * Source/WebCore/WebCore.xcodeproj/project.pbxproj: * Source/WebCore/platform/graphics/TileConfigurationChangeIdentifier.h: Added. * Source/WebCore/platform/graphics/TiledBacking.h: * Source/WebCore/platform/graphics/ca/TileController.cpp: (WebCore::TileController::activeConfigurationChange const): (WebCore::TileController::destroyExistingTileConfigurationChange): (WebCore::TileController::addPendingTilesToActiveTileConfigurationChangeIfNeeded): (WebCore::TileController::makeTileConfigurationChange): (WebCore::TileController::didPrepareContentForTile): (WebCore::TileController::swapPrimaryGridWithPendingTileGrid): (WebCore::TileController::setNeedsDisplay): (WebCore::TileController::setNeedsDisplayInRect): (WebCore::TileController::setContentsScale): (WebCore::TileController::revalidateTiles): (WebCore::TileController::tileSize const): (WebCore::TileController::rectForTile const): (WebCore::TileController::computeTileSize): (WebCore::TileController::didRevalidateTiles): (WebCore::TileController::tileGridExtent const): (WebCore::TileController::retainedTileBackingStoreMemory const): (WebCore::TileController::tileCoverageRect const): * Source/WebCore/platform/graphics/ca/TileController.h: * Source/WebCore/platform/graphics/ca/TileGrid.cpp: (WebCore::TileGrid::revalidateTiles): * Source/WebCore/platform/graphics/ca/TileGrid.h: * Source/WebCore/platform/graphics/ca/TileGridTypes.h: Added. * Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/AsyncPDFRenderer.h: * Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/AsyncPDFRenderer.mm: (WebKit::AsyncPDFRenderer::willRepaintTile): (WebKit::AsyncPDFRenderer::willRemoveTile): (WebKit::AsyncPDFRenderer::willRepaintAllTiles): (WebKit::AsyncPDFRenderer::tilingScaleFactorDidChange): (WebKit::AsyncPDFRenderer::prepareContentForTile): (WebKit::AsyncPDFRenderer::didPrepareContentForTile): (WebKit::AsyncPDFRenderer::cancelPrepareContentForTile): (WebKit::AsyncPDFRenderer::didCancelTileConfigurationChange): (WebKit::AsyncPDFRenderer::paintPDFIntoBuffer): (WebKit::AsyncPDFRenderer::transferBufferToMainThread): (WebKit::AsyncPDFRenderer::tileConfigurationChangeCompletionHandler): (WebKit::AsyncPDFRenderer::pdfContentScaleChanged): (WebKit::AsyncPDFRenderer::pdfContentChangedInRect): * Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/PDFDiscretePresentationController.h: * Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/PDFDiscretePresentationController.mm: (WebKit::PDFDiscretePresentationController::applyWheelEventDelta): (WebKit::PDFDiscretePresentationController::updateLayersOnLayoutChange): * Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/PDFPresentationController.h: (WebKit::PDFPresentationController::LayoutChangeInformation::scaleFactorChangedAfterInitialLayout const): * Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/PDFScrollingPresentationController.h: * Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/PDFScrollingPresentationController.mm: (WebKit::PDFScrollingPresentationController::updateLayersOnLayoutChange): * Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.h: * Source/WebKit/WebProcess/Plugins/PDF/UnifiedPDF/UnifiedPDFPlugin.mm: (WebKit::UnifiedPDFPlugin::updateLayerHierarchy): (WebKit::UnifiedPDFPlugin::setScaleFactor): (WebKit::UnifiedPDFPlugin::updateLayout): * Source/WebKit/WebProcess/WebPage/wc/GraphicsLayerWC.cpp:
|
EWS run on current version of this PR (hash cbececa) Details |
|
Succeeded by #35189 |
🛠 mac-safer-cpp
cbececa
cbececa