-
Notifications
You must be signed in to change notification settings - Fork 1.3k
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Simplify frame scheduling logic in RemoteLayerTreeDrawingArea.
https://bugs.webkit.org/show_bug.cgi?id=259999 <rdar://113657855> Reviewed by Simon Fraser. Previously, both scheduleRenderingUpdate and external calls to triggerRenderingUpdate would wait for the next displayDidRefresh if one was pending. scheduleRenderingUpdate would check for this explicitly at call time. TriggerRenderingUpdate would always run updateRendering on a 0ms timer, and then check at that point and reschedule (by setting m_deferredRenderingUpdateWhileWaitingForBackingStoreSwap=true). This reverses the logic of triggerRenderingUpdate to be the same as scheduleRenderingUpdate by making them use the same code (a new scheduleRenderingUpdate function with an enum to specify the exact behaviour). In very rare cases this could be a behaviour change (since we're checking state at a different point). The difference between these two is now more clear, in the case where there isn't a displayDidRefresh pending, schedule has an extra async task dispatch that trigger does not. This difference affects performance benchmark results, so trying to remove it is outside the scope of this patch. It should now never be possible for displayDidRefresh to be pending when updateRendering is called, so m_deferredRenderingUpdateWhileWaitingForBackingStoreSwap is removed. Setting of m_displayDidRefreshIsPending=true happens earlier, since we can sometimes recurse back in to trigger rendering during a rendering update. Existing internal callers of triggerRenderingUpdate (and startRenderingUpdateTimer) have been changed to use the enum version of scheduleRenderingUpdate to make it clearer. Most of these are using the as soon as possible variant, but almost certainly don't need to and could be changed. The two call sites that synchronously called updateRendering have also been changed to scheduleRenderingUpdate(AsSoonAsPossible). These likely weren't synchronous previously (since updateRendering aborted and rescheduled if displayDidRefresh was pending), but it was non-deterministic. Making them always just schedule seems a lot safer and easier to understand. Renames m_waitingForBackingStoreSwap to m_displayDidRefreshIsPending since that's the name of the message we're actually waiting for. The logic in ::displayDidRefresh cleaned up in response to the above changes, since most of the complexity it checked for no longer exists. * Source/WebKit/WebProcess/WebPage/DrawingArea.h: * Source/WebKit/WebProcess/WebPage/RemoteLayerTree/RemoteLayerTreeDrawingArea.h: (WebKit::RemoteLayerTreeDrawingArea::displayDidRefreshIsPending const): * Source/WebKit/WebProcess/WebPage/RemoteLayerTree/RemoteLayerTreeDrawingArea.mm: (WebKit::RemoteLayerTreeDrawingArea::setRootCompositingLayer): (WebKit::RemoteLayerTreeDrawingArea::updateGeometry): (WebKit::RemoteLayerTreeDrawingArea::setLayerTreeStateIsFrozen): (WebKit::RemoteLayerTreeDrawingArea::forceRepaint): (WebKit::RemoteLayerTreeDrawingArea::setExposedContentRect): (WebKit::RemoteLayerTreeDrawingArea::startRenderingUpdateTimer): (WebKit::RemoteLayerTreeDrawingArea::triggerRenderingUpdate): (WebKit::RemoteLayerTreeDrawingArea::updateRendering): (WebKit::RemoteLayerTreeDrawingArea::displayDidRefresh): (WebKit::RemoteLayerTreeDrawingArea::activityStateDidChange): (WebKit::RemoteLayerTreeDrawingArea::dispatchAfterEnsuringDrawing): (WebKit::RemoteLayerTreeDrawingArea::scheduleRenderingUpdateTimerFired): (WebKit::RemoteLayerTreeDrawingArea::scheduleRenderingUpdate): * Source/WebKit/WebProcess/WebPage/mac/RemoteLayerTreeDrawingAreaMac.mm: (WebKit::RemoteLayerTreeDrawingAreaMac::applyTransientZoomToPage): Canonical link: https://commits.webkit.org/266884@main
- Loading branch information
1 parent
2f426da
commit 7dd240a
Showing
5 changed files
with
90 additions
and
64 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters