Implement atomic reporting of UI changes in Runtime Scheduler #41157
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
facebook-github-bot
added
the
CLA Signed
|
This pull request was exported from Phabricator. Differential Revision: D49536327 |
rubennorte
force-pushed
the
export-D49536327
branch
from
84d586f to
e7b72c4
Compare
rubennorte
added a commit
to rubennorte/react-native
that referenced
this pull request
Oct 23, 2023
…ok#41157) Summary: This is internal until we're ready to test this outside of Meta. Changelog: [internal] ## Context In the new architecture, every time we commit a new tree in React we send a transaction to the host platform to make all the necessary mutations in the underlying native views. This can be bad for user experience, because the user might see quick changes to the UI in succession for related changes. It also breaks the semantics of things like layout effects and ref callbacks, which are core to the React programming model and should work across all platforms. The main semantic that this behavior breaks in React Native is that layout effects are supposed to be blocking for paint. That means that any state updates (or UI mutations) done in layout effects should be applied to the UI atomically with the original changes that triggered them, so users see a single update where the final state is applied. This doesn't work in React Native as none of the commits coming from React are blocked waiting for effects, and instead they're all mounted/applied as they come. This isn't only a problem for React, but also for future Web-like APIs that rely on microtasks. Those are also assumed to block paint in browsers, and we don't support that behavior either. ## Changes Now that we're adding support for a well-defined event loop in React Native, we can add a new step to notify UI changes to the host platform in specific points in time, after macrotasks and microtasks are done (the "Update the rendering" step defined on the [Web specification](https://html.spec.whatwg.org/multipage/webappapis.html#event-loop-processing-model)). This implements that step in the new `RuntimeScheduler`. This works by batching all the notifications from the `UIManager` to `MountingCoordinator` and calling all those methods from `RuntimeScheduler` at the right time. There will be cases where the notifications will be to mount the same tree multiple times, but the mounting coordinator already handles this correctly (would mount the last version of the tree for each surface ID the first time, and be a no-op the other times). This change will reduce the amount of mount operations we do on the main thread, which means that we could potentially remove the push model from Android if performance is acceptable with this. NOTE: This only works with the modern runtime scheduler, and only makes sense when used with microtasks enabled too and background executor disabled. Differential Revision: D49536327
|
This pull request was exported from Phabricator. Differential Revision: D49536327 |
Base commit: 615057c |
rubennorte
force-pushed
the
export-D49536327
branch
from
e7b72c4 to
4b69f20
Compare
rubennorte
added a commit
to rubennorte/react-native
that referenced
this pull request
Oct 24, 2023
…ok#41157) Summary: This is internal until we're ready to test this outside of Meta. Changelog: [internal] ## Context In the new architecture, every time we commit a new tree in React we send a transaction to the host platform to make all the necessary mutations in the underlying native views. This can be bad for user experience, because the user might see quick changes to the UI in succession for related changes. It also breaks the semantics of things like layout effects and ref callbacks, which are core to the React programming model and should work across all platforms. The main semantic that this behavior breaks in React Native is that layout effects are supposed to be blocking for paint. That means that any state updates (or UI mutations) done in layout effects should be applied to the UI atomically with the original changes that triggered them, so users see a single update where the final state is applied. This doesn't work in React Native as none of the commits coming from React are blocked waiting for effects, and instead they're all mounted/applied as they come. This isn't only a problem for React, but also for future Web-like APIs that rely on microtasks. Those are also assumed to block paint in browsers, and we don't support that behavior either. ## Changes Now that we're adding support for a well-defined event loop in React Native, we can add a new step to notify UI changes to the host platform in specific points in time, after macrotasks and microtasks are done (the "Update the rendering" step defined on the [Web specification](https://html.spec.whatwg.org/multipage/webappapis.html#event-loop-processing-model)). This implements that step in the new `RuntimeScheduler`. This works by batching all the notifications from the `UIManager` to `MountingCoordinator` and calling all those methods from `RuntimeScheduler` at the right time. There will be cases where the notifications will be to mount the same tree multiple times, but the mounting coordinator already handles this correctly (would mount the last version of the tree for each surface ID the first time, and be a no-op the other times). This change will reduce the amount of mount operations we do on the main thread, which means that we could potentially remove the push model from Android if performance is acceptable with this. NOTE: This only works with the modern runtime scheduler, and only makes sense when used with microtasks enabled too and background executor disabled. Reviewed By: javache Differential Revision: D49536327
|
This pull request was exported from Phabricator. Differential Revision: D49536327 |
rubennorte
added a commit
to rubennorte/react-native
that referenced
this pull request
Oct 24, 2023
…ok#41157) Summary: This is internal until we're ready to test this outside of Meta. Changelog: [internal] ## Context In the new architecture, every time we commit a new tree in React we send a transaction to the host platform to make all the necessary mutations in the underlying native views. This can be bad for user experience, because the user might see quick changes to the UI in succession for related changes. It also breaks the semantics of things like layout effects and ref callbacks, which are core to the React programming model and should work across all platforms. The main semantic that this behavior breaks in React Native is that layout effects are supposed to be blocking for paint. That means that any state updates (or UI mutations) done in layout effects should be applied to the UI atomically with the original changes that triggered them, so users see a single update where the final state is applied. This doesn't work in React Native as none of the commits coming from React are blocked waiting for effects, and instead they're all mounted/applied as they come. This isn't only a problem for React, but also for future Web-like APIs that rely on microtasks. Those are also assumed to block paint in browsers, and we don't support that behavior either. ## Changes Now that we're adding support for a well-defined event loop in React Native, we can add a new step to notify UI changes to the host platform in specific points in time, after macrotasks and microtasks are done (the "Update the rendering" step defined on the [Web specification](https://html.spec.whatwg.org/multipage/webappapis.html#event-loop-processing-model)). This implements that step in the new `RuntimeScheduler`. This works by batching all the notifications from the `UIManager` to `MountingCoordinator` and calling all those methods from `RuntimeScheduler` at the right time. There will be cases where the notifications will be to mount the same tree multiple times, but the mounting coordinator already handles this correctly (would mount the last version of the tree for each surface ID the first time, and be a no-op the other times). This change will reduce the amount of mount operations we do on the main thread, which means that we could potentially remove the push model from Android if performance is acceptable with this. NOTE: This only works with the modern runtime scheduler, and only makes sense when used with microtasks enabled too and background executor disabled. Reviewed By: javache Differential Revision: D49536327
rubennorte
force-pushed
the
export-D49536327
branch
from
4b69f20 to
ca2ec45
Compare
|
This pull request was exported from Phabricator. Differential Revision: D49536327 |
1 similar comment
|
This pull request was exported from Phabricator. Differential Revision: D49536327 |
rubennorte
added a commit
to rubennorte/react-native
that referenced
this pull request
Oct 24, 2023
…ok#41157) Summary: Pull Request resolved: facebook#41157 This is internal until we're ready to test this outside of Meta. Changelog: [internal] ## Context In the new architecture, every time we commit a new tree in React we send a transaction to the host platform to make all the necessary mutations in the underlying native views. This can be bad for user experience, because the user might see quick changes to the UI in succession for related changes. It also breaks the semantics of things like layout effects and ref callbacks, which are core to the React programming model and should work across all platforms. The main semantic that this behavior breaks in React Native is that layout effects are supposed to be blocking for paint. That means that any state updates (or UI mutations) done in layout effects should be applied to the UI atomically with the original changes that triggered them, so users see a single update where the final state is applied. This doesn't work in React Native as none of the commits coming from React are blocked waiting for effects, and instead they're all mounted/applied as they come. This isn't only a problem for React, but also for future Web-like APIs that rely on microtasks. Those are also assumed to block paint in browsers, and we don't support that behavior either. ## Changes Now that we're adding support for a well-defined event loop in React Native, we can add a new step to notify UI changes to the host platform in specific points in time, after macrotasks and microtasks are done (the "Update the rendering" step defined on the [Web specification](https://html.spec.whatwg.org/multipage/webappapis.html#event-loop-processing-model)). This implements that step in the new `RuntimeScheduler`. This works by batching all the notifications from the `UIManager` to `MountingCoordinator` and calling all those methods from `RuntimeScheduler` at the right time. There will be cases where the notifications will be to mount the same tree multiple times, but the mounting coordinator already handles this correctly (would mount the last version of the tree for each surface ID the first time, and be a no-op the other times). This change will reduce the amount of mount operations we do on the main thread, which means that we could potentially remove the push model from Android if performance is acceptable with this. NOTE: This only works with the modern runtime scheduler, and only makes sense when used with microtasks enabled too and background executor disabled. Reviewed By: javache Differential Revision: D49536327 fbshipit-source-id: be6814ca130cfde866d75c2d915308f3dcbb45dd
rubennorte
force-pushed
the
export-D49536327
branch
from
ca2ec45 to
7633910
Compare
rubennorte
added a commit
to rubennorte/react-native
that referenced
this pull request
Oct 24, 2023
…ok#41157) Summary: This is internal until we're ready to test this outside of Meta. Changelog: [internal] ## Context In the new architecture, every time we commit a new tree in React we send a transaction to the host platform to make all the necessary mutations in the underlying native views. This can be bad for user experience, because the user might see quick changes to the UI in succession for related changes. It also breaks the semantics of things like layout effects and ref callbacks, which are core to the React programming model and should work across all platforms. The main semantic that this behavior breaks in React Native is that layout effects are supposed to be blocking for paint. That means that any state updates (or UI mutations) done in layout effects should be applied to the UI atomically with the original changes that triggered them, so users see a single update where the final state is applied. This doesn't work in React Native as none of the commits coming from React are blocked waiting for effects, and instead they're all mounted/applied as they come. This isn't only a problem for React, but also for future Web-like APIs that rely on microtasks. Those are also assumed to block paint in browsers, and we don't support that behavior either. ## Changes Now that we're adding support for a well-defined event loop in React Native, we can add a new step to notify UI changes to the host platform in specific points in time, after macrotasks and microtasks are done (the "Update the rendering" step defined on the [Web specification](https://html.spec.whatwg.org/multipage/webappapis.html#event-loop-processing-model)). This implements that step in the new `RuntimeScheduler`. This works by batching all the notifications from the `UIManager` to `MountingCoordinator` and calling all those methods from `RuntimeScheduler` at the right time. There will be cases where the notifications will be to mount the same tree multiple times, but the mounting coordinator already handles this correctly (would mount the last version of the tree for each surface ID the first time, and be a no-op the other times). This change will reduce the amount of mount operations we do on the main thread, which means that we could potentially remove the push model from Android if performance is acceptable with this. NOTE: This only works with the modern runtime scheduler, and only makes sense when used with microtasks enabled too and background executor disabled. Reviewed By: javache Differential Revision: D49536327
rubennorte
force-pushed
the
export-D49536327
branch
from
7633910 to
2898b48
Compare
|
This pull request was exported from Phabricator. Differential Revision: D49536327 |
…ok#41157) Summary: This is internal until we're ready to test this outside of Meta. Changelog: [internal] ## Context In the new architecture, every time we commit a new tree in React we send a transaction to the host platform to make all the necessary mutations in the underlying native views. This can be bad for user experience, because the user might see quick changes to the UI in succession for related changes. It also breaks the semantics of things like layout effects and ref callbacks, which are core to the React programming model and should work across all platforms. The main semantic that this behavior breaks in React Native is that layout effects are supposed to be blocking for paint. That means that any state updates (or UI mutations) done in layout effects should be applied to the UI atomically with the original changes that triggered them, so users see a single update where the final state is applied. This doesn't work in React Native as none of the commits coming from React are blocked waiting for effects, and instead they're all mounted/applied as they come. This isn't only a problem for React, but also for future Web-like APIs that rely on microtasks. Those are also assumed to block paint in browsers, and we don't support that behavior either. ## Changes Now that we're adding support for a well-defined event loop in React Native, we can add a new step to notify UI changes to the host platform in specific points in time, after macrotasks and microtasks are done (the "Update the rendering" step defined on the [Web specification](https://html.spec.whatwg.org/multipage/webappapis.html#event-loop-processing-model)). This implements that step in the new `RuntimeScheduler`. This works by batching all the notifications from the `UIManager` to `MountingCoordinator` and calling all those methods from `RuntimeScheduler` at the right time. There will be cases where the notifications will be to mount the same tree multiple times, but the mounting coordinator already handles this correctly (would mount the last version of the tree for each surface ID the first time, and be a no-op the other times). This change will reduce the amount of mount operations we do on the main thread, which means that we could potentially remove the push model from Android if performance is acceptable with this. NOTE: This only works with the modern runtime scheduler, and only makes sense when used with microtasks enabled too and background executor disabled. Reviewed By: javache Differential Revision: D49536327
rubennorte
force-pushed
the
export-D49536327
branch
from
2898b48 to
787c595
Compare
|
This pull request was exported from Phabricator. Differential Revision: D49536327 |
|
This pull request was successfully merged by @rubennorte in b5dae01. When will my fix make it into a release? | Upcoming Releases |
Othinn
pushed a commit
to Othinn/react-native
that referenced
this pull request
Oct 30, 2023
…ok#41157) Summary: Pull Request resolved: facebook#41157 This is internal until we're ready to test this outside of Meta. Changelog: [internal] ## Context In the new architecture, every time we commit a new tree in React we send a transaction to the host platform to make all the necessary mutations in the underlying native views. This can be bad for user experience, because the user might see quick changes to the UI in succession for related changes. It also breaks the semantics of things like layout effects and ref callbacks, which are core to the React programming model and should work across all platforms. The main semantic that this behavior breaks in React Native is that layout effects are supposed to be blocking for paint. That means that any state updates (or UI mutations) done in layout effects should be applied to the UI atomically with the original changes that triggered them, so users see a single update where the final state is applied. This doesn't work in React Native as none of the commits coming from React are blocked waiting for effects, and instead they're all mounted/applied as they come. This isn't only a problem for React, but also for future Web-like APIs that rely on microtasks. Those are also assumed to block paint in browsers, and we don't support that behavior either. ## Changes Now that we're adding support for a well-defined event loop in React Native, we can add a new step to notify UI changes to the host platform in specific points in time, after macrotasks and microtasks are done (the "Update the rendering" step defined on the [Web specification](https://html.spec.whatwg.org/multipage/webappapis.html#event-loop-processing-model)). This implements that step in the new `RuntimeScheduler`. This works by batching all the notifications from the `UIManager` to `MountingCoordinator` and calling all those methods from `RuntimeScheduler` at the right time. There will be cases where the notifications will be to mount the same tree multiple times, but the mounting coordinator already handles this correctly (would mount the last version of the tree for each surface ID the first time, and be a no-op the other times). This change will reduce the amount of mount operations we do on the main thread, which means that we could potentially remove the push model from Android if performance is acceptable with this. NOTE: This only works with the modern runtime scheduler, and only makes sense when used with microtasks enabled too and background executor disabled. Reviewed By: javache Differential Revision: D49536327 fbshipit-source-id: fabcbd6a6fb89a851f4c2b4ebefbb330a6ad3a18
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Summary:
This is internal until we're ready to test this outside of Meta.
Changelog: [internal]
Context
In the new architecture, every time we commit a new tree in React we send a transaction to the host platform to make all the necessary mutations in the underlying native views.
This can be bad for user experience, because the user might see quick changes to the UI in succession for related changes. It also breaks the semantics of things like layout effects and ref callbacks, which are core to the React programming model and should work across all platforms.
The main semantic that this behavior breaks in React Native is that layout effects are supposed to be blocking for paint. That means that any state updates (or UI mutations) done in layout effects should be applied to the UI atomically with the original changes that triggered them, so users see a single update where the final state is applied. This doesn't work in React Native as none of the commits coming from React are blocked waiting for effects, and instead they're all mounted/applied as they come.
This isn't only a problem for React, but also for future Web-like APIs that rely on microtasks. Those are also assumed to block paint in browsers, and we don't support that behavior either.
Changes
Now that we're adding support for a well-defined event loop in React Native, we can add a new step to notify UI changes to the host platform in specific points in time, after macrotasks and microtasks are done (the "Update the rendering" step defined on the Web specification).
This implements that step in the new
RuntimeScheduler. This works by batching all the notifications from theUIManagertoMountingCoordinatorand calling all those methods fromRuntimeSchedulerat the right time.There will be cases where the notifications will be to mount the same tree multiple times, but the mounting coordinator already handles this correctly (would mount the last version of the tree for each surface ID the first time, and be a no-op the other times).
This change will reduce the amount of mount operations we do on the main thread, which means that we could potentially remove the push model from Android if performance is acceptable with this.
NOTE: This only works with the modern runtime scheduler, and only makes sense when used with microtasks enabled too and background executor disabled.
Differential Revision: D49536327
See react-native-community/discussions-and-proposals#744