You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Commit 0ede810
Browse filesBrowse the repository at this point in the historyBrowse files
Pull the stop transaction of a surface in the pull model
In the pull model a commit only notifies the UI thread, and
pullAndExecuteTransaction pulls only surfaces found in the binding's surface
registry. stopSurfaceWithSurfaceHandler removes the surface from the registry
before SurfaceHandler::stop() commits its empty tree, so nothing pulled that
transaction. Mounting override delegates such as LayoutAnimations and C++
Animated never saw its Deletes. The pull cannot happen after stop(): the
shadow tree is destroyed at its end, which revokes the MountingCoordinator.
schedulerShouldRenderTransactions now pulls and executes a commit of an
unregistered surface on the commit thread, as the push model does with
accumulated props. Registered surfaces are pulled on the UI thread as before.
That check reads the registry inside the commit, so stopSurface(int) no longer
holds the registry lock across stop(): it takes the surface out of the
registry first, as stopSurfaceWithSurfaceHandler does.
startSurfaceWithSurfaceHandler (bridgeless) now adds the surface to the
registry before SurfaceHandler::start(), as startSurface and
startSurfaceWithConstraints already do. Otherwise a commit made while the
surface starts would be pulled on the commit thread and queued, and the UI
thread's pull of the next commit would mount ahead of it. Now only a stopping
surface commits outside the registry.
So a registered surface may not be running yet, e.g. a restarted surface, which
keeps its id, with a pull or mount report left from its previous run.
pullAndExecuteTransaction and reportMount now skip a surface that is not
running.
native_startSurfaceWithSurfaceHandler_pullModel_mountsCommitDuringStartInOrder
commits from another thread in an on-surface-start callback while the start
waits, then commits again on the UI thread, and checks the mounted order. It
also passes without this change; it fails, with the views mounted as [42, 43],
if the surface is added to the registry after start().
Copy file name to clipboardExpand all lines: packages/react-native/ReactAndroid/src/main/jni/react/fabric/test_helper/FabricMountingManagerTestHelper.cpp
Copy file name to clipboardExpand all lines: packages/react-native/ReactAndroid/src/main/jni/react/fabric/test_helper/FabricMountingManagerTestHelper.h
+3Lines changed: 3 additions & 0 deletions
Original file line number
Diff line number
Diff line change
@@ -43,6 +43,7 @@ class FabricMountingManagerTestHelper : public jni::HybridClass<FabricMountingMa
Copy file name to clipboardExpand all lines: packages/react-native/ReactAndroid/src/test/java/com/facebook/react/fabric/FabricMountingManagerInstrumentationTest.kt
Copy file name to clipboardExpand all lines: packages/react-native/ReactAndroid/src/test/java/com/facebook/react/fabric/FabricMountingManagerTestHelper.kt
0 commit comments