Bug 257290 – Multiple RemoteLayerTreeDrawingAreas should not be driven from a single display refresh monitor

• Status: RESOLVED
• Resolution: FIXED
• Component: Layout and Rendering

[Matt Woodrow]

RemoteLayerTreeDisplayRefreshMonitor is mostly just a wrapper around asking the RemoteLayerTreeDrawingArea to schedule when it wants to display next. This is specific to that drawing area, and can be throttled if the drawing area is failing to commit layer trees as fast as expected.

DisplayRefreshMonitorManager caches DisplayRefreshMonitors, and shares them between all WebCore::Page/RenderingUpdateSchedulers on the same Display. This means if we have multiple RemoteLayerTreeDrawingAreas on the same display (and in the same process), we'll be sharing a single RemoteLayerTreeDisplayRefreshMonitor, driven at the effective rate of one of the drawing areas.

It looks like DrawingAreaCoordinatedGraphics has the same problem, and synthesises a unique DisplayID for each DrawingArea to ensure a unique display refresh monitor for each -  https://searchfox.org/wubkat/rev/dab28312bc80bc475196b7d6221b060347254e33/Source/WebKit/WebProcess/WebPage/CoordinatedGraphics/DrawingAreaCoordinatedGraphics.cpp#565-569

I think RenderingUpdateScheduler as a DisplayRefreshMonitorClient isn't the right abstraction for what behaviour we want.

I think we should make WebCore::Page ask the ChromeClient/DrawingArea more directly to schedule the next rendering update, and DrawingArea implementations can choose to use DisplayRefreshMonitor to implement this if they choose. RemoteLayerTreeDrawingArea can just use its internal IPC-based scheduling, and we shouldn't need RemoteLayerTreeDisplayRefreshMonitor.

[Matt Woodrow]

Pull request: https://github.com/WebKit/WebKit/pull/14327

[Radar WebKit Bug Importer]

<rdar://problem/109953504>

[EWS]

Committed 264920@main (fa67a2625225): <https://commits.webkit.org/264920@main>

Reviewed commits have been landed. Closing PR #14327 and removing active labels.