Budget Android pre-mounting by the display's frame, not a 60 Hz one

[YevheniiKotyrlo]

Summary:

MountItemDispatcher.dispatchPreMountItems stops pre-mounting at frameTimeNanos + FRAME_TIME_NS / 2, where FRAME_TIME_NS is a 60 Hz frame. That budget is 8.33 ms on every display: all of a 120 Hz frame and more than a 144 Hz one, so a frame that pre-mounts a large backlog on a fast display spends its whole budget before it traverses.

The dispatcher now pre-mounts for half of the default display's current frame, and never longer than half of a 30 Hz frame: a display running below 30 Hz, such as an adaptive panel idling at 1 Hz, gets 16.67 ms instead of half of its long frame. DisplayFrameInterval reads the refresh rate from DisplayManager when FabricUIManager initializes and again whenever the display reports a change, so a frame reads a cached interval rather than the display; a display that reports no refresh rate keeps today's 8.33 ms. The loop reads com.facebook.react.common.SystemClock so a test can drive it.

Changelog:

[ANDROID] [FIXED] - Budget view pre-mounting by the display's current refresh rate instead of a 60 Hz frame

Test Plan:

MountItemDispatcherTest (new) covers the budget at 30, 48, 60, 90, 120, 144, 165, 185 and 240 Hz, at 1, 10 and 24 Hz, while the display reports no refresh rate, after the display drops from 120 Hz back to 60 Hz, and across a skipped frame. DisplayFrameIntervalTest (new) covers reading the default display's frame from 1 Hz to 240 Hz, following a refresh-rate change the display reports, keeping the last frame once stopped, and reporting no frame while the display reports no refresh rate.

Every queued item takes 1 ms. With the 60 Hz budget, the rate cases fail: expected:<{30=[17, 48=11, 60=9, 90=6, 120=5, 144=4, 165=4, 185=3, 240=3]}> but was:<{30=[9, 48=9, 60=9, 90=9, 120=9, 144=9, 165=9, 185=9, 240=9]}> and expected:<{1=[17, 10=17, 24=17]}> but was:<{1=[9, 10=9, 24=9]}>. Without the 16.67 ms ceiling, the cases below 30 Hz fail: expected:<{1=[17, 10=17, 24=17]}> but was:<{1=[20, 10=20, 24=20]}>.

• ./gradlew :packages:react-native:ReactAndroid:testDebugUnitTest -PenableWarningsAsErrors=true: 730 tests, 0 failures
• ./gradlew :packages:react-native:ReactAndroid:compileReleaseKotlin :packages:react-native:ReactAndroid:compileReleaseJavaWithJavac: clean
• node ./scripts/format-kotlin.js --check and node ./scripts/format-java.js --check: clean

I didn't run the full Android build, the template and HelloWorld app builds, or the Android e2e jobs locally.

[javache]

The refresh rate can change dynamically, so forever locking to the smallest time may be suboptimal - can we try to use the screen's current refresh rate?

[YevheniiKotyrlo]

Updated in 35f8355: pre-mounting now takes half of the default display's current frame, read from DisplayManager when the display reports a change rather than on every frame, so a drop from 120 Hz back to 60 Hz restores the 60 Hz budget. MountItemDispatcherTest covers that switch and DisplayFrameIntervalTest the listener.

[YevheniiKotyrlo]

Follow-up in 3d780fb: below 60 Hz the budget stays at today's 8.33 ms instead of half of the longer frame, since an adaptive panel idling at 1 Hz would otherwise pre-mount for 500 ms, and a display that reports no refresh rate gets 8.33 ms as well.

[javache]

an adaptive panel idling at 1 Hz would otherwise pre-mount for 500 ms

While 500ms is extreme, I do think it's reasonable for us to use more than 8ms here when the system has reduced frame rate (eg in low power mode?). Maybe make the max the equivalent of 30hz / 16ms?

[YevheniiKotyrlo]

9e2fa9c caps the budget at half of a 30 Hz frame (16.67 ms) instead of 8.33 ms; a display that reports no refresh rate keeps 8.33 ms.