[Fiber] Animation priority work#7466
Conversation
ghost
added
|
Rebased: https://github.com/sebmarkbage/react/tree/fiberhighpriority (You can allow edits from maintainers now which is good for this use case. :) ) |
| }, | ||
|
|
||
| performHighPriWork(fn: Function) { | ||
| NoopRenderer.performWithPriority(HighPriority, fn); |
There was a problem hiding this comment.
I'm not sure we want to expose this full granularity in the API we expose to renderers. I've been thinking about a different API for scheduling that would be based on expiration date buckets. If we don't expose it to users, maybe we also shouldn't expose it to renderers?
There was a problem hiding this comment.
I agree it's too much to expose to renderers. I only added it here because I needed some way to test it. Any suggestions?
There was a problem hiding this comment.
If we don't expose it to users, maybe we also shouldn't expose it to renderers?
I can imagine renderers might need at least some more granular control than a user, because there are certain scheduling tricks that can only be controlled at the renderer level. E.g. I had assumed that the deprioritization that happens when hidden={true} (or style={{ display: hidden }}) would eventually be handled by the renderer via some API, rather than being embedded in Fiber itself. Or a renderer might want to use a different priority for specific types of events? Curious what your plans are for that.
There was a problem hiding this comment.
Yea, I think the deprioritization case needs to be handled by the renderer somehow. However, I don't see a good way to expose it as an API to schedule a specific priority.
I think possibly that prepareUpdate could return the priority level. However, currently that happens after the children has already rendered. Would need to split children update from props update - which I want to do anyway.
It could also be an explicit API like isOffscreen(...) or something.
I'm not sure if the deprioritization use case make much sense for a renderer to do in another case than Offscreen so it probably isn't granular anyway.
acdlite
force-pushed
the
fiberhighpriority
branch
from
b2f5945 to
577409d
Compare
|
@sebmarkbage Rebased. I also checked the box to allow edits from maintainers on this and the other PRs :) |
| if (defaultPriority === NoWork) { | ||
| return; | ||
| } | ||
| if (defaultPriority >= LowPriority) { |
There was a problem hiding this comment.
This should actually be defaultPriority >= HighPriority.
We ended up overloading the term which needs to be undone. We should rename scheduleHighPriWork to scheduleAnimationWork because HighPriority is the highest priority that goes in to requestIdleCallback. We should only do AnimationPriority work during requestAnimationFrame.
Additionally, SynchronousPriority should not use scheduleHighPriWork so it should throw in that case. At least until we fix it.
acdlite
force-pushed
the
fiberhighpriority
branch
from
925f7df to
8b48a9b
Compare
acdlite
force-pushed
the
fiberhighpriority
branch
from
8b48a9b to
d238f8c
Compare
acdlite
force-pushed
the
fiberhighpriority
branch
3 times, most recently
from
6d1fff6 to
d238f8c
Compare
Adds the ability to schedule and perform high priority work. In the noop renderer, this is exposed using a method `performHighPriWork(fn)` where the function is executed and all updates in that scope are given high priority. To do this, the scheduler keeps track of a default priority level. A new function `performWithPriority(priority, fn)` changes the default priority before calling the function, then resets it afterwards.
"High" and "low" priority are overloaded terms. There are priority
levels called HighPriority and LowPriority. Meanwhile, there are
functions called {perform,schedule}HighPriWork, which corresponds
to requestAnimationFrame, and {perform,schedule}LowPriWork, which
corresponds to requestIdleCallback. But in fact, work that has
HighPriority is meant to be scheduled with requestIdleCallback.
This is super confusing.
To address this, {perform,schedule}HighPriWork has been renamed
to {perform,schedule}AnimationWork, and
{perform,schedule}LowPriWork has been renamed to
{perform,schedule}DeferredWork. HighPriority and LowPriority
remain the same.
sebmarkbage
force-pushed
the
fiberhighpriority
branch
from
d238f8c to
c00ed35
Compare
* High priority work
Adds the ability to schedule and perform high priority work. In the
noop renderer, this is exposed using a method `performHighPriWork(fn)`
where the function is executed and all updates in that scope are given
high priority.
To do this, the scheduler keeps track of a default priority level.
A new function `performWithPriority(priority, fn)` changes the default
priority before calling the function, then resets it afterwards.
* Rename overloaded priority terms
"High" and "low" priority are overloaded terms. There are priority
levels called HighPriority and LowPriority. Meanwhile, there are
functions called {perform,schedule}HighPriWork, which corresponds
to requestAnimationFrame, and {perform,schedule}LowPriWork, which
corresponds to requestIdleCallback. But in fact, work that has
HighPriority is meant to be scheduled with requestIdleCallback.
This is super confusing.
To address this, {perform,schedule}HighPriWork has been renamed
to {perform,schedule}AnimationWork, and
{perform,schedule}LowPriWork has been renamed to
{perform,schedule}DeferredWork. HighPriority and LowPriority
remain the same.
* Priority levels merge fix
(cherry picked from commit 6144212)
4 participants
Adds the ability to schedule and perform high priority work. In the noop renderer, this is exposed using a method
performHighPriWork(fn)where the function is executed and all updates in that scope are given high priority.To do this, the scheduler keeps track of a default priority level. A new function
performWithPriority(priority, fn)changes the default priority before calling the function, then resets it afterwards.