[Webkit-unassigned] [Bug 256548] RemoteLayerTreeDisplayRefreshMonitor::requestRefreshCallback doesn't wait for display link.

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=256548

--- Comment #2 from Matt Woodrow <mattwoodrow at apple.com> ---
Some notes on the current behaviour:

Each call to requestRefreshCallback (from RenderingUpdateScheduler::scheduleRenderingUpdate()) results in an immediately triggered rendering update, and then a second rendering update as a result of a displayDidRefresh from the UI process after the first is committed.

When we're animating (and rendering updates result in a layer tree commit every time), we avoid doing two rendering updates per-frame because of m_waitingForBackingStoreSwap checks, which cause the 'immediate' ones to be omitted.

The UI process side can't differentiate between a commit that came late because it was a slow, and a no-op rendering update that didn't send a commit at all. All it knows is that no layer tree commit had arrived at the point we get to the next display link update, and goes into 'missed commit' mode.

If we missed the commit due to a no-op rendering update (WebProcess became idle), then when we next have work to do (which kicks off the immediate rendering update), the UI-side will immediately respond with a displayDidRefresh (and not wait for a display link callback), since it thinks we were just super-slow.

The UI process side schedules sending a displayDidRefresh (either immediately, or on the next display link callback) in response to a commit, not the WebProcess deciding to schedule one. 
That means if we do a commit in the WebProcess, and then run some other long-running task (like JS execution), the next displayDidRefresh message will be sitting in our event queue already when that task completes, even if the task didn't call scheduleRenderingUpdate until after the display link callback time.
That differs from WebProcess side rendering, where the displayDidRefresh event isn't generated until the display link callback *after* we call scheduleRenderingUpdate.
Not sure which behaviour is preferable here, but it probably should be a conscious decision.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20230511/3d25e57b/attachment-0001.htm>