Summary:
Fix crashes in LayoutAnimations:
1) It is valid to omit create, update, delete configs
2) When extracting SRT from a matrix, ignoring skew properties
3) Provide valid telemetry from LayoutAnimations transactions
Unrelated to crashes: to help debugging and until onSuccess/onError callbacks are working, log any configuration parsing errors.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D22050736
fbshipit-source-id: e59418ecad0f9bfd20a2b4976557e39020c2d101
Summary:
Changelog: [Internal]
# Problem
`MountingCoordinator` holds a pointer to instance of `MountingOverrideDelegate` which becomes invalid.
# Solution
Use `std::weak_ptr` instead of raw pointer so it is possible to tell whether the pointer is expired.
Reviewed By: JoshuaGross
Differential Revision: D21905351
fbshipit-source-id: c7bf9635742a6ec086a03ba83202e46e1f1f373f
Summary:
This is the V1 implementation of Fabric Core LayoutAnimations.
The intention is to structure this in such a way that it's easy for each platform to customize the "AnimationDriver" class (to do platform-specific optimizations) without changing the KeyFrameManager at all.
In the future, this structure and architecture should allow us to iterate faster on new animation APIs.
Changelog: [Internal] Support for LayoutAnimations in Fabric
Reviewed By: mdvacca
Differential Revision: D21675808
fbshipit-source-id: b3ef44729bb8b6217f90760aec9737276c9601d1
Summary:
This is the V1 implementation of Fabric Core LayoutAnimations.
The intention is to structure this in such a way that it's easy for each platform to customize the "AnimationDriver" class (to do platform-specific optimizations) without changing the KeyFrameManager at all.
In the future, this structure and architecture should allow us to iterate faster on new animation APIs.
TODOs:
- Use std::chrono for timekeeping
Changelog: [Internal] Support for LayoutAnimations in Fabric
Reviewed By: shergin
Differential Revision: D17486030
fbshipit-source-id: 95c72cf9fc2b4bf3fe652fbd249cf2ad113033c7
Summary:
An evolution of D20633188 but more performant.
There are three optimized paths before the slow path.
The first optimized path tries to pair identical nodes from old/new tree, and generate Update mutations, until we hit nodes that are different (indicating either a remove or an insert). This already existed.
The next two optimizations, introduced by Tim in his JS pseudocode, were inspired by ReactJS's diffing algorithm. They work in cases where the rest of the nodes are (1) all removals/deletes or (2) all creates+inserts.
Finally, if those final two optimized paths can't run, it's because there is a mix of delete+remove, create+insert, and "move" operations, mixed at the beginning, middle, and/or end of the list.
This has slightly better average/best-case complexity as the previous implementation.
In particularly pathological cases where all nodes are arbitrarily reordered, or reversed, for instance (ABCDE->EDCBA) the algorithm has the same complexity as the previous algorithm (quadratic).
For now iOS is pinned to the older differ
Changelog: [Internal] Experiment to optimize diffing algorithm in Fabric
Reviewed By: shergin
Differential Revision: D20684094
fbshipit-source-id: d29fba95a0328156c023e1c87804f23770ee1d91
Summary:
On Android/when printing to logcat, output is truncated to a certain max length; outputting a massive string as a single log item will cause some of it to be truncated. In the case of the mutations list and shadow node description, most of it is truncated.
Easy fix: split into lines and log each line. This isn't necessary on iOS but works fine.
I also removed the conditional and changed to an assert. Most of the time when we're using this block of code, it's because we want to see all mutations; and unless we reintroduce a bug into the core, the assert is never hit and so (before this change) the conditional would never be true and we'd never see this output. It's more generally useful to be able to see this output if the `RN_SHADOW_TREE_INTROSPECTION` macro is defined.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D19378929
fbshipit-source-id: 2f5dffeef7608823ac1ba092090d8c2ab5e965e1
Summary:
Having those arguments optional does not really make anything easier to use; on another side that makes it hard finding problems caused by missing that parameter.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D18797337
fbshipit-source-id: c119b8f6a03994072edb45e39337e33b0f8b602f
Summary:
With this diff (and maybe other coming in the future), we are enforcing a model where Fabric Core actively/architecturally prevents `jsi::Object` to overlive `UIManager`. That never was a promise that but I think it's achievable; it should help to eliminate the whole class of possible crashes (application layer still must ensure that Scheduler is deallocated before `jsi::Runtime`).
Clearing all pointers to `ShadowNode`s in `MountingCoordinator` prevents from extending the lifetime of ShadowNodes stored inside revoked `MountingCoordinator` (the lifetime of `MountingCoordinator` is up to application layer).
That should help prevent crashes (not all of them!) caused by `jsi::Object`s overliving `jsi::Runtime`.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D18333708
fbshipit-source-id: 4391998b8f805563cfaff834fc56e85b98bc4d68
Summary:
`MountingCoordinator::waitForTransaction()` allows waiting for a new coming transaction synchronously, as efficient as waiting for a mutex.
This feature can be used to implement more high-level synchronous rendering APIs.
Reviewed By: mdvacca
Differential Revision: D17629425
fbshipit-source-id: acd91b941e4d6d43bc4518f332a1604e14506be9
Summary:
MountingCoordinator is a borderline between Core and Mounting. Some of Core design constraints are impossible/impractical to enforce on Mounting layer, so we have to handle all of those cases in `MountingCoordinator`.
One of the constrains is that all ShadowNodes implicitly depend on associated ComponentDescriptor instances without retaining them (retaining is expensive and creates a retain cycle).
The problem is that the Mounting layer can call `MountingCoordinator::pull()` at any moment (even after the whole Core is already destroyed). To prevent this, the owner of a `MountingCoordinator` on the Core side calls `revoke()` right before being deallocated (right before the moment the owner cannot guarantee the constraint).
Reviewed By: JoshuaGross
Differential Revision: D17272295
fbshipit-source-id: ba8b02eab8f84cce68aa65c1ad36950cd2498049
Joshua Gross
Samuel Susla
Ishan Khot
Valentin Shergin
Andres Suarez