[webkit-changes] [WebKit/WebKit] a33d2c: updateRendering() gets stuck at the wrong framerat...

[Tim Horton]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: a33d2c717ecb2870f364d3952bd340b4f54728a7
      https://github.com/WebKit/WebKit/commit/a33d2c717ecb2870f364d3952bd340b4f54728a7
  Author: Tim Horton <thorton at apple.com>
  Date:   2023-08-29 (Tue, 29 Aug 2023)

  Changed paths:
    M Source/WebCore/PAL/pal/spi/cocoa/QuartzCoreSPI.h
    M Source/WebKit/UIProcess/RemoteLayerTree/ios/RemoteLayerTreeDrawingAreaProxyIOS.mm

  Log Message:
  -----------
  updateRendering() gets stuck at the wrong framerate when thermal throttling changes
https://bugs.webkit.org/show_bug.cgi?id=260846
rdar://112799115

Reviewed by Wenson Hsieh and Simon Fraser.

It turns out that `maximumRefreshRate` is actually "the maximum frame rate you can
achieve given current throttling behaviors", not "the frame rate of the display".
That means that, when throttling states change, maximumRefreshRate can change too.

We currently do not respond to changes in maximumRefreshRate. This means that we
can get stuck with an incorrect `maximumRefreshRate` (and `preferredFramesPerSecond`,
which is downstream of it).

* Source/WebKit/UIProcess/RemoteLayerTree/ios/RemoteLayerTreeDrawingAreaProxyIOS.mm:
(-[WKDisplayLinkHandler initWithDrawingAreaProxy:]):
(-[WKDisplayLinkHandler invalidate]):
(-[WKDisplayLinkHandler observeValueForKeyPath:ofObject:change:context:]):
(-[WKDisplayLinkHandler didChangeNominalFramesPerSecond]):
When the CADisplayLink's CADisplay's `refreshRate` changes, reconfigure the display, which
results in communicating the new maximum frame rate back to WebCore and also (indirectly)
updating the CADisplayLink's `preferredFramesPerSecond`.

* Source/WebCore/PAL/pal/spi/cocoa/QuartzCoreSPI.h:
Add CADisplay SPI.

Canonical link: https://commits.webkit.org/267440@main