Summary:
changelog: [internal]
Pulling a function from class since it doesn't use any of the ivars.
Reviewed By: RSNara
Differential Revision: D30766917
fbshipit-source-id: 219d9b7d3bc0b110b659d7188f5e3877c7b480ff
Summary:
changelog: [internal]
In this diff, we delete default initialised for ShadowViewMutation to prevent accidentally creating empty ShadowViewMutation.
The other initialiser is made private and all of its uses are migrated to designated initialisers. This makes for safer API.
Reviewed By: RSNara
Differential Revision: D30774900
fbshipit-source-id: d2064bf08409850e75e13ad06558b7980a7f5d8d
Summary:
changelog: [internal]
I'm chasing down a crash in LayoutAnimations, it would help me to simulate the memory access which causes the crash to learn where the bad memory is coming from.
Reviewed By: RSNara
Differential Revision: D30776840
fbshipit-source-id: 1e97fac28ba2df37ba3e47ec2c110043c3823e70
Summary:
changelog: [internal]
This looks like a bug where the author did not intend the conversion to boolean. This means that `onlyMutationIsUpdate` was evaluated to true even if more than 1 animation was in the vector.
Reviewed By: RSNara
Differential Revision: D30767172
fbshipit-source-id: 0ef47b65a5d8ef07d774d9e0b358e5642dc0a9ea
Summary:
changelog: [intenal]
The variable is never read, removing it.
Reviewed By: RSNara
Differential Revision: D30767134
fbshipit-source-id: de72740f9dc7ad10d651129404fe4df093e6206d
Summary:
changelog: [internal]
Add a log behind feature flag to learn more about missing component descriptor.
Component descriptor should never be missing, that's a state of program that is impossible as far as I can tell. This logic was introduced in D22216030 (https://github.com/facebook/react-native/commit/6342e6e3f11219391ac3296d41233735af7e6cad) and I think it is just cover the real cause of crashes in LA on iOS.
Reviewed By: RSNara
Differential Revision: D30765947
fbshipit-source-id: 6843384e02529de2f024c59c61ae21b8682ac371
Summary:
changelog: [internal]
Just moving two functions to separate file.
Reviewed By: RSNara
Differential Revision: D30765732
fbshipit-source-id: e85e749c2910f6f38f07e56b23a21fb9f1cbc9b5
Summary:
changelog: [internal]
Prefer `unordered_set` over `vector`. Makes for nicer APIs and has better performance characteristics.
Reviewed By: RSNara
Differential Revision: D30756215
fbshipit-source-id: d259da07f8f0d5837441dc8ba11c00324aac3fa4
Summary:
changelog: [internal]
Maybe invalid keyframe animation shouldn't be queued. This adds a fix behind feature flag to verify if it fixes iOS crashes.
Reviewed By: RSNara
Differential Revision: D30730005
fbshipit-source-id: 8a2bb54c449449a95d14d51a1a78bfaccad61877
Summary:
changelog: [internal]
Group public, protected and private methods in header and implementation file. Nothing else is changed in this diff.
Reviewed By: RSNara
Differential Revision: D30729103
fbshipit-source-id: 047bfb86794caedddcf6569ffeee224fee811794
Summary:
changelog: [internal]
There was extra bookkeeping associated with lifetime of `LayoutAnimationCallbackWrapper`. We can just copy it into runtimeExecutor lambda to manage its life cycle and delete `jsi::Function` once it was called.
Reviewed By: RSNara
Differential Revision: D30728210
fbshipit-source-id: 6fc60ee83846cb73648f1c09e5aaf1ed04bd0817
Summary:
changelog: [internal]
Use set instead of vector. It makes for nicer API to check if the element exists.
Reviewed By: cortinico
Differential Revision: D30728211
fbshipit-source-id: 7b7cc1e94bb82a44b064e2945a753adbbce5dc2c
Summary:
Unfortunately, parsing some props requires stateful context - namely, PlatformColor on Android. We explored several different options but they all seemed inferior to the approach of using ContextContainer, and most would require using global state.
By introducing this change everywhere as early as possible, we can avoid later pain. It is likely that some prop, on some platform, will require this mechanism. We'll be ready for it!
Because we can pass a constref of the ContextContainer through to all props and because the context and context data is never retained by prop parsers, perf and memory hit should be ~0.
This diff contains core changes only. Leaf changes to all props structs and conversions files will be in next diff(s).
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D29838789
fbshipit-source-id: f5090e7f02eb6e8fbe0ef4dd201e7d12104a3e3c
Summary:
The new C++ Differ has been validated on Android and iOS. Delete the old code path.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D28904330
fbshipit-source-id: 2e0d8682f6b2a79f9758ed8b7b92809060835815
Summary:
Root nodes doesn't have a ComponentDescriptor that can be looked up via this mechanism, and we probably shouldn't be animating Root nodes anyway (?). This is a debug-only assert but could be causing issues in production.
The fix is simple - just don't animate any changes to a root node.
Changelog: [Internal]
Reviewed By: Nick177
Differential Revision: D28856396
fbshipit-source-id: 43fa0aa723b03b031fee22e0563eb63cc86239b3
Summary:
Builds on previous diff. Instead of running a single animation to completion, queues up an animation and then spams mutations that could conflict with the animation.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D28357892
fbshipit-source-id: 6ca83a56dded629d8a1444360f1d02037661a5ef
Summary:
Add unit tests for Layout Animations.
This first batch generates a random mutation, then animates it to completion.
I found one issue with UPDATE+REMOVE+INSERT animation consistency. That shouldn't cause any crashes in production, but is a chance to improve consistency of mutations overall - and could in theory point to memory corruption, though it's somewhat unlikely.
I ran with randomized seeds, found issues, fixed them, re-ran to ensure issues were fixed, rinsed and repeated. At the end I was able to run dozens of times (with random seeds) and found nothing.
The next step is to repeatedly generate mutations that conflict with ongoing animations.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D28343750
fbshipit-source-id: c1c60d89a31be3ac05d57482f0af3c482b866abe
Summary:
When REMOVE animations finish, they are hitting asserts in StubViewTree because of UPDATEs and REMOVEs being out-of-order. By simply not forcing REMOVEs to happen before UPDATEs, this problem seems to go away.
Long-term (in a couple weeks, likely) I want to add unit tests to catch all cases like this, but I'm comfortable with this change since it does fix a known assert failure.
Changelog: [Internal]
Differential Revision: D28086223
fbshipit-source-id: eb77ea94d76e996d7b2cb37038ce6f2a9799f8b4
Summary:
Make these logs more readable/useful and add debug print of ShadowView hashes in one place.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D27585135
fbshipit-source-id: 5f526856d893c32015d8b480522580732fda0cc6
Summary:
Temporarily disable due to build failures.
This is debug-only and I've never hit these asserts, so this should be safe; though it should be reenabled during active development of LA.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D27505224
fbshipit-source-id: b3d6d2184d8f226d6f82d3fe0ae6303813c8356a
Summary:
Changelog: [Internal] enable support for C++ 17.
C++ 17 in React Native targets.
Short and comprehensive list of C++ features:
https://github.com/AnthonyCalandra/modern-cpp-features#c17-language-features
Reviewed By: JoshuaGross
Differential Revision: D27431145
fbshipit-source-id: e8da6fe9d70e9b7343a8caec21cdbeb043478575
Summary:
To ensure that we're eventually deleting all ShadowViews from the StubViewTree and from the mounting layer, make sure that we always queue conflicts if they're DELETE instructions, including for virtual nodes.
I was able to hit this by running some extremely complex animations. It is extremely unlikely that even a single user is hitting this in prod. Therefore, while this is the right change to make, I don't expect (for example) OOMs to go down at all.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D27492935
fbshipit-source-id: bce332feb15229af271cc6e14b8367ebcb36536b
Summary:
This is more insurance against future changes than fixing any existing bugs. In a very small number of cases it looks like this sorting isn't working, for reasons that are not easily reproducible (way less than 1 in 10000 times for me, if that) and not obvious, since we're sorting vectors in a canonical and straightforward way.
Again, this insures that logic won't change in the future.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D27492936
fbshipit-source-id: 7f47e44ac1101915e1a0433c8f0a50a3c6a0c7b3
Summary:
When displaying instructions in debug logs, also print ShadowView hash to make it easier to reconstruct a series of events.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D27492938
fbshipit-source-id: 276a080a4afcfb4aa0aafc215e2ccd56ef849fcf
Summary:
We have no evidence of this happening, but it matches other bail-out cases that already exist in this function. If we
fail something that would have been an assert in debug mode, bail out so we don't return garbage values in production.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D27449775
fbshipit-source-id: 5b85016c9611484b615debec514d12a984e6b1ff
Summary:
This chunk of code is repeated 3x in the codebase with minor variations. Consolidate as `queueFinalMutationsForCompletedKeyFrame`.
Should be no changes in behavior.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D27407766
fbshipit-source-id: 196f0d4c7868007f0d103b024feb4450640a3f62
Summary:
This probably won't compile outside of debug mode, because variables are unused outside of asserts. Don't do any of this outside of debug mode.
This path is also a pessimisation, we shouldn't need to run it unless we're running in ultra-conservative debug mode.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D27407767
fbshipit-source-id: 71a8d025463c85d65cd2bc193a19953b97669d84
Summary:
Log final when synthetic final mutations are generated at the end of an animation.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D27407768
fbshipit-source-id: 0e9aface54bcca73dfa5ea263a8474db7c47c078
Summary:
Call getAndEraseConflictingAnimations recursively, to clean up any conflicting animations.
With a specific sequence of mutation instructions, it is possible that an animation on a tree is set up, and the entire tree needs to be cleaned up if a parent is deleted, say.
This can happen especially if rapidly mutating trees in such a way that invokes view flattening and unflattening (which is not recommended, but is certainly possible).
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D27407776
fbshipit-source-id: 5125250f051c58870692f8fdc43ed23da5058a7f
Summary:
When reconstructing a second animation based on a conflict with a first, we want to ensure we set 'viewPrev' of the second animation properly.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D27407777
fbshipit-source-id: 8fcc72c4c5fadaab4287824a944ad21230f2f97d
Summary:
In general, when an animation is interrupted or completed, we want to forcibly "flush" an update that will make the StubViewTree/mounting layer consistent with the ShadowTree.
However, in cases where a conflict creates a second animation and stops the first, we simply updated the "viewPrev" of the second animation and smoothly transition to it.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D27407774
fbshipit-source-id: 928363867d8994c9d69c53154a07bda94f954afa
Summary:
Detect conflicts not just when a node is updated, but when its parent is DELETEd or CREATEd.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D27407781
fbshipit-source-id: 719d9a8822bf691d9059073a30d8b5ccb50eece1
Summary:
pull out tag so it's easier to read
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D27407770
fbshipit-source-id: e7d2a3ce8e4ac55b6446cddc8c39e73a18fa7170
Summary:
One of the struggles with the LA engine is to make sure that LA doesn't break the StubViewTree. In particular, we have strict requirements that the "oldShadowView" with every mutation matches exactly what is in the shadow tree, so it appears that there is a linear progression of ShadowNodes for every mutation instruction.
This is a struggle to do with the current setup, requires some wacky code, and doesn't work properly. Instead of spreading REMOVE/DELETE (especially) or INSERT/UPDATE instructions across multiple keyframes, we now allow keyframes to have multiple "final" instructions to execute,
which makes it much easier to keep state consistent.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D27407769
fbshipit-source-id: 3a709503dc30be69efc345690cb1920eb9591e9a
Summary:
Just makes it easier to log and inspect these values.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D27407778
fbshipit-source-id: 68e93d100b56bc9065f0ff1370260412d729312d
Summary:
On Android we have the notion of "virtual views", which are defined consistently but the logic is scattered and duplicated throughout the codebase.
The logic exists to mark nodes that exist in the ShadowTree, but not the View tree. We want to CREATE, UPDATE, and DELETE them on the platform, but not INSERT or REMOVE
them. They basically exist as EventEmitter objects.
The only issue with this is (1) duplicated code, which opened the possibility for inconsistent definition (2) StubViewTree did not account for virtualized views, which caused
assert crashes in debug mode for certain LayoutAnimations on Android.
By moving the definition to ShadowViewMutation and accounting for it in StubViewTree, asserts are correct and consistent on all platforms.
This was not caught until recently, because, until recently, no asserts actually ran on Android.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D27001199
fbshipit-source-id: eb29085317037ba8a286d7813bdd57095ad4746f
Pieter De Baets
Samuel Susla
Joshua Gross