Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: 3fe5ba4547a3ece6a1ab059a583e183b06e6da54
https://github.com/WebKit/WebKit/commit/3fe5ba4547a3ece6a1ab059a583e183b06e6da54
Author: Gerald Squelart <[email protected]>
Date: 2023-07-30 (Sun, 30 Jul 2023)
Changed paths:
M Source/WebKit/UIProcess/RemoteLayerTree/RemoteLayerTreeDrawingAreaProxy.h
M
Source/WebKit/UIProcess/RemoteLayerTree/RemoteLayerTreeDrawingAreaProxy.messages.in
M Source/WebKit/UIProcess/RemoteLayerTree/RemoteLayerTreeDrawingAreaProxy.mm
M
Source/WebKit/WebProcess/WebPage/RemoteLayerTree/RemoteLayerTreeDrawingArea.mm
Log Message:
-----------
Ignore willCommitLayerTree and commitLayerTreeNotTriggered when reordered
after a commitLayerTree
https://bugs.webkit.org/show_bug.cgi?id=259632
rdar://110498860
Reviewed by Matt Woodrow.
The normal sequence of RemoteLayerTreeDrawingAreaProxy messages should normally
be:
willCommit(1) commit(1) notTriggered(next commit 2) willCommit(2) commit(2) ...
However this could be disrupted by
RemoteLayerTreeDrawingAreaProxy::waitForDidUpdateActivityState, which
waits for the first commit message and runs it immediately! This could lead to
handling them in this order:
willCommit(1) commit(1) **commit(2)** notTriggered(next commit 2) willCommit(2)
...
The main issue is that the notTriggered(next commit 2) handler pauses further
display refresh callbacks,
which would normally have been restarted by the later-sent commit(2), so the
rendering doesn't get updated
anymore. In some applications like Mail, this may result in blank email bodies.
The solution here is to detect such re-orderings, and produce the same effects
as if they had run in the
expected order. Details below:
*
Source/WebKit/UIProcess/RemoteLayerTree/RemoteLayerTreeDrawingAreaProxy.messages.in:
Add `nextCommitTransactionID` to CommitLayerTreeNotTriggered, to know which
commit they should
precede (and hence which commit should come after).
*
Source/WebKit/WebProcess/WebPage/RemoteLayerTree/RemoteLayerTreeDrawingArea.mm:
(WebKit::RemoteLayerTreeDrawingArea::displayDidRefresh):
Send the next commit transaction ID with CommitLayerTreeNotTriggered.
* Source/WebKit/UIProcess/RemoteLayerTree/RemoteLayerTreeDrawingAreaProxy.h:
Record the last processed CommitLayerTree transaction ID.
* Source/WebKit/UIProcess/RemoteLayerTree/RemoteLayerTreeDrawingAreaProxy.mm:
(WebKit::RemoteLayerTreeDrawingAreaProxy::commitLayerTreeNotTriggered):
If this message's next-to-commit transaction ID is lower than or equal to the
last-received committed
transaction ID, this means that the commit was reordered and handled before
this not-triggered, so nothing
should be done here; especially, display-refresh callbacks should not be
paused, and the scrolling update
should happen in the upcoming not-triggered that corresponds to the
last-received commit.
This should be rare, so a log message is appropriate to expose this event.
(WebKit::RemoteLayerTreeDrawingAreaProxy::willCommitLayerTree):
Similar to the message above, if the will-commit transaction ID is not smaller
than the last-received
committed transaction ID, it means that this message was reordered and can be
ignored. Its effect would
have already been handled by the commit message (see below.)
(WebKit::RemoteLayerTreeDrawingAreaProxy::commitLayerTreeTransaction):
Update the last processed transaction ID.
Also, if the pending transaction ID is lower than this commit's transaction ID,
it means this message is
being preemptively handled sooner, so the will-commit effect is simulated by
updating the pending
transaction ID now -- the already sent will-commit will be ignored later on.
Canonical link: https://commits.webkit.org/266421@main
_______________________________________________
webkit-changes mailing list
[email protected]
https://lists.webkit.org/mailman/listinfo/webkit-changes
