[scheduler] Yield many times per frame, no rAF #16214
Conversation
Adds experimental flag to yield many times per frame using a message event loop, instead of the current approach of guessing the next vsync and yielding at the end of the frame. This new approach forgoes a `requestAnimationFrame` entirely. It posts a message event and performs a small amount of work (5ms) before yielding to the browser, regardless of where it might be in the vsync cycle. At the end of the event, if there's work left over, it posts another message event. This should keep the main thread responsive even for really high frame rates. It also shouldn't matter if the hardware frame rate changes after page load (our current heuristic only detects if the frame rate increases, not decreases). The main risk is that yielding more often will exacerbate main thread contention with other browser tasks. Let's try it and see.
|
React: size: 0.0%, gzip: -0.0% Details of bundled changes.Comparing: c0830a0...5b706be react
scheduler
Generated by 🚫 dangerJS |
acdlite
force-pushed
the
scheduler-message-loop
branch
2 times, most recently
from
7cc5b84 to
5b706be
Compare
|
Why not use setTimeOut 0 directly? What the difference between setTimeOut and Message Channel? |
|
Promise polyfill was originally used in React, why not use Promise? Now queueMicroTask is living standard, why not use it? |
|
@SyMind Microtasks are continuously executed until the microtask queue on the event loop is empty which means a higher-pri task such as one for user interaction would be blocked by React. |
We prefer MessageChannel because of the 4ms setTimeout clamping |
|
I have discussed which APIs are suitable for task scheduling：lizuncong/mini-react#22 |
|
Hello! Your E-mail has been recieved and I will respond you as soon as possible.Best wishes!
|
Adds experimental flag to yield many times per frame using a message event loop, instead of the current approach of guessing the next vsync and yielding at the end of the frame.
This new approach forgoes a
requestAnimationFrameentirely. It posts a message event and performs a small amount of work (5ms) before yielding to the browser, regardless of where it might be in the vsync cycle. At the end of the event, if there's work left over, it posts another message event.This should keep the main thread responsive even for really high frame rates. It also shouldn't matter if the hardware frame rate changes after page load (our current heuristic only detects if the frame rate increases, not decreases).
The main risk is that yielding more often will exacerbate main thread contention with other browser tasks.
I'm also not sure to what extent message events are throttled when the tab is backgrounded, relative to
requestAnimationFrameorsetTimeout. I'm starting with the assumption thatmessageevents fire with at least the same priority as timers, but I'll need to confirm.Let's try it and see.