I introduce the ReactDOMFrameScheduling module which just exposes
rIC and rAF.
The polyfill works by scheduling a requestAnimationFrame, store the time
for the start of the frame, then schedule a postMessage which gets
scheduled after paint. The deadline is set to time + frame rate.
By separating the idle call into a separate event tick we ensure that
layout, paint and other browser work is counted against the available time.
The frame rate is dynamically adjusted by tracking the minimum time between
two rAF callbacks. This is not perfect because browsers can schedule
multiple callbacks to catch up after a long frame. To compensate for this
we only adjust if two consecutive periods are faster than normal.
This seems to guarantee that we will hit frame deadlines and we don't end
up dropping frames. However, there is still some lost time so we risk
starving by not having enough idle time.
Especially Firefox seems to have issues keeping up on the triangle demo
However, that is also true for native rIC in Firefox. It seems like more
render work is scheduled on the main thread pipeline and also that JS
execution just generally has more overhead.
* FiberDebugger uses packages built in local
* Fix key warnings in FiberDebugger
* Remove react packages from package.json and yarn.lock for using pacakges built in local
* Remove fiber.js from `files` in package.json
This builds a `react-dom-fiber.js` bundle which exposes ReactDOMFiber.
This allows early experiments with the new Fiber reconciler.
I also expose it in the npm package through `react-dom/fiber`.
Dan Abramov