Skip to content

Keep non-layout animations on the synchronous path while another view animates layout - #58772

Open
bartlomiejbloniarz wants to merge 1 commit into
mainfrom
export-D122570616
Open

bartlomiejbloniarz wants to merge 1 commit into
mainfrom
export-D122570616

Conversation

@bartlomiejbloniarz

Copy link
Copy Markdown
Contributor

Summary:
The shared animation backend decided per surface whether a frame's animated props go through a shadow tree commit or straight to the mounted views. As soon as one view animated a layout prop, every animated view on that surface went through the commit path for the whole animation, including views that only animate transform or opacity. Besides the extra commit work, on Android this moved those views from updatePropsSynchronously to regular mounts. There the synchronous mount props cache (overrideBySynchronousMountPropsAtMountingAndroid) replaced the incoming transform with its last synchronously written value, so the view froze while the other view's layout animation ran and jumped when it ended.

The decision is now made per view. SurfaceUpdates holds a surface's mutations keyed by view tag, and applySurfaceUpdates splits them into views with layout updates, which go through commitUpdates, and the rest, which are applied synchronously. AnimationMutation and AnimationMutations move to AnimationMutation.h, still included by AnimationBackend.h. AnimatedPropsRegistry::update reads the frame's batches instead of the merged per-surface map.

Changelog:

[General] [Fixed] - A view animating only non-layout props on the shared animation backend no longer freezes while another view on the surface animates a layout prop

Differential Revision: D122570616

… animates layout

Summary:
The shared animation backend decided per surface whether a frame's animated props go through a shadow tree commit or straight to the mounted views. As soon as one view animated a layout prop, every animated view on that surface went through the commit path for the whole animation, including views that only animate `transform` or `opacity`. Besides the extra commit work, on Android this moved those views from `updatePropsSynchronously` to regular mounts. There the synchronous mount props cache (`overrideBySynchronousMountPropsAtMountingAndroid`) replaced the incoming transform with its last synchronously written value, so the view froze while the other view's layout animation ran and jumped when it ended.

The decision is now made per view. `SurfaceUpdates` holds a surface's mutations keyed by view tag, and `applySurfaceUpdates` splits them into views with layout updates, which go through `commitUpdates`, and the rest, which are applied synchronously. `AnimationMutation` and `AnimationMutations` move to `AnimationMutation.h`, still included by `AnimationBackend.h`. `AnimatedPropsRegistry::update` reads the frame's batches instead of the merged per-surface map.

## Changelog:

[General] [Fixed] - A view animating only non-layout props on the shared animation backend no longer freezes while another view on the surface animates a layout prop

Differential Revision: D122570616
@meta-cla meta-cla Bot added the CLA Signed This label is managed by the Facebook bot. Authors need to sign the CLA before a PR can be reviewed. label Sep 30, 2026
@facebook-github-tools facebook-github-tools Bot added p: Software Mansion Partner: Software Mansion Partner p: Facebook Partner: Facebook labels Sep 30, 2026

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

CLA Signed This label is managed by the Facebook bot. Authors need to sign the CLA before a PR can be reviewed. meta-exported p: Facebook Partner: Facebook p: Software Mansion Partner: Software Mansion Partner

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant