Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix issues with skipping reanimated commit #6498

Merged

Conversation

bartlomiejbloniarz
Copy link
Contributor

@bartlomiejbloniarz bartlomiejbloniarz commented Sep 9, 2024

Summary

When working on #6330 I missed the fact that the pleaseSkipReanimatedCommit mechanism is not only a performance optimization (preventing us from applying some changes twice a frame). It's main role is to actually prevent reanimated from starving RN out. It could happen that RN is trying to apply some heavy commit while an animation is running. If during that commit reanimated applies its own changes, then the RN commit will fail and another attempt will be made. Since reanimated runs a commit in every frame, then the RN commit might continue failing until the animation is over, which is very very very bad.

In this PR I changed the "skip" name to "pause" since it better describes the intent behind it. I also reverted the change where the skip flag was reset in performOperations. This was done to ensure that if some changes are applied through updateProps after the commit hook has already gathered all updates, but before reanimated commits have been unpaused, then these changes are not lost. Unfortunately this would lead to reanimated blocking heavy RN commits from being applied. Now the skip flag is reset in the ReanimatedMountHook (as it was before #6330), and if there are any changes that would be lost by skipping reanimated commits, we run an additional commit in the ReanimatedMountHook

Test plan

Check if the example app works fine

@bartlomiejbloniarz bartlomiejbloniarz marked this pull request as ready for review September 12, 2024 12:48
Copy link
Member

@piaskowyk piaskowyk left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good to me 👍

@bartlomiejbloniarz bartlomiejbloniarz added this pull request to the merge queue Sep 16, 2024
Merged via the queue into main with commit a3de2b2 Sep 16, 2024
16 checks passed
@bartlomiejbloniarz bartlomiejbloniarz deleted the @bartlomiejbloniarz/fix-skip-reanimated-commit branch September 16, 2024 09:34
bartlomiejbloniarz added a commit that referenced this pull request Sep 19, 2024
## Summary

When working on #6330 I missed the fact that the
`pleaseSkipReanimatedCommit` mechanism is not only a performance
optimization (preventing us from applying some changes twice a frame).
It's main role is to actually prevent reanimated from starving RN out.
It could happen that RN is trying to apply some heavy commit while an
animation is running. If during that commit reanimated applies its own
changes, then the RN commit will fail and another attempt will be made.
Since reanimated runs a commit in every frame, then the RN commit might
continue failing until the animation is over, which is very very very
bad.

In this PR I changed the "skip" name to "pause" since it better
describes the intent behind it. I also reverted the change where the
skip flag was reset in `performOperations`. This was done to ensure that
if some changes are applied through `updateProps` after the commit hook
has already gathered all updates, but before reanimated commits have
been unpaused, then these changes are not lost. Unfortunately this would
lead to reanimated blocking heavy RN commits from being applied. Now the
skip flag is reset in the `ReanimatedMountHook` (as it was before
#6330), and if there are any changes that would be lost by skipping
reanimated commits, we run an additional commit in the
`ReanimatedMountHook`

## Test plan
Check if the example app works fine
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants