Summary:
Previously the pointScaleFactor field was not being compared properly in LayoutMetrics equality method.
This diff fixes that
Reviewed By: shergin
Differential Revision: D15303555
fbshipit-source-id: 8863e9e1fbad15b43400afc32b97bf6d252cbe55
Summary: After this change, all measuring operations based on `LayoutableShadowNode::getRelativeLayoutMetrics` will take into account the transformation matrices provided by shadow nodes. This will allow implementing scroll-offset-aware and custom-transform-aware measuring.
Reviewed By: JoshuaGross, mdvacca
Differential Revision: D15219259
fbshipit-source-id: 1d7cd8c0ee4406f4dd0002cd442dc0679391922b
Summary:
`LayoutableShadowNode::getTransform` returns a transform object that represents transformations that will/should
be applied on top of regular layout metrics by mounting layer.
Reviewed By: mdvacca
Differential Revision: D15219262
fbshipit-source-id: e7aeb85b5f7e2fce3f8faf9dfcaee5dae3217d36
Summary:
Previously we computed the list of nodes that need to be notified about layout changes using a list of mutation instructions. That was fine, but that's not really compatible with some other changes that I plan to make, so I decided to change it (make it better).
Besides the better design (debatable; fewer dependencies to unrelated moving pieces), here is why I believe the new way is more performant:
* The new approach has no `dynamic_casts`, whereas the previous has tons of them (two per a mutation). If a `dynamic_cast` takes 10 ns, for 500 nodes it can take up to 5ms only for casts. (Non-scientific assumption.)
* After removing dependency to mutation instruction, we can enable flattening for views which have `onLayout` event.
Reviewed By: mdvacca
Differential Revision: D15110725
fbshipit-source-id: 31a657ccfd02441734ad1d71a833653223163289
Summary: `kFloatUndefined` means "no value here", but in this particular case, we have to have `Infinity` value that represents maximum available space.
Reviewed By: mdvacca
Differential Revision: D15155190
fbshipit-source-id: d2de20681ad04da7444331eff44b93d2bd0200e3
Summary: Same algorithm using a new API.
Reviewed By: JoshuaGross
Differential Revision: D14423509
fbshipit-source-id: c40f61fdd001f68785512c304941f523585d641c
Summary:
If the `HasNewLayout` flag is `false`, we should not copy the data from YGStyle/YGLayout to ShadowNode because the node can be already sealed and because it's unnecessary. Previously we workaround this case with a special check in `setLayoutMetrics` method, but that can be unreliable because of some side-effects related to pixel rounding and comparing floats.
The new approach is much more robust and explicit.
Reviewed By: JoshuaGross
Differential Revision: D14496939
fbshipit-source-id: deddb14d2206c5bd3f22154d0ea682e3c5888901
Summary: These default implementations are never being used. Removing them allowing to ensure that flags inside YGNode have same values as flags in YogaLayoutableShadowNode. That also saves a couple of bytes in size of ShadowNode.
Reviewed By: JoshuaGross
Differential Revision: D14496938
fbshipit-source-id: c43f9c8a2eec054f728ff54a6573668eccda55fb
Summary:
Accidentally I noticed that the signature of Folly's hash_combine is different from boost's one.
The Folly's one is:
`size_t hash_combine(const T& t, const Ts&... ts)`, so the first argument is immutable and the method returns the result normally.
It means that all hashes that we compute in Fabric using `hash_combine` were `0`.
So I fixed it.
I have no idea why this difference exists, but some modern papers suggest that folly's variant has good chances to be standardized.
E.g.: http://open-std.org/JTC1/SC22/WG21/docs/papers/2017/p0814r0.pdf
Technically, it should improve performance, but I doubt that it can be more than 1-2 ms per screen TTI.
Reviewed By: JoshuaGross
Differential Revision: D14430380
fbshipit-source-id: 97da999ee5780b940bb789bc3eb5bf9f89c194ca
Summary: The hope is that it will remove many unnececery allocations improving overal perfromance.
Reviewed By: mdvacca
Differential Revision: D14249198
fbshipit-source-id: f0442b3919ccead0582a3190dea0e33d517d85f6
Summary:
This pull request removes the designated initializer in `LayoutMetrics.h`. This will help improve the portability of this file.
[General] [Changed] - Fabric: Remove designated initializer in LayoutMetrics.h
Pull Request resolved: https://github.com/facebook/react-native/pull/23758
Differential Revision: D14320526
Pulled By: shergin
fbshipit-source-id: 076ad389d0985d5213b521a2ffaca4ca7ae31599
Summary: `LayoutConstraints::clamp` clamps the provided `Size` between the `minimumSize` and `maximumSize` bounds of this `LayoutConstraints`.
Reviewed By: mdvacca
Differential Revision: D14205770
fbshipit-source-id: 4799608cead393451d334e47dd6906255699a1e8
Summary: Use a folly LRU implementation to cache results of ParagraphShadowNode::measure, which Yoga asks for repeatedly. Should have a substantial speed improvement on Android and iOS, or at least that's the dream.
Reviewed By: mdvacca
Differential Revision: D13795808
fbshipit-source-id: 5716af0fe0517a72716e48113c8125bb788735d7
Summary:
The generic method that returns relative (to some specified node) layout metrics.
We need this as a building block to implement `UIManager.measure*()` methods family.
Reviewed By: mdvacca
Differential Revision: D12932549
fbshipit-source-id: 79064551d32b0cd40e72dc87d0ed194e3779ba29
Summary: We are moving to more stable APIs removing all mentiones of the effort name from the codebase.
Reviewed By: mdvacca
Differential Revision: D12912894
fbshipit-source-id: 4a0c6b9e7454b8b14e62d419e9e9311dc0c56e7a
Summary:
Trivial.
We have to proxy layout directions as well as min and max sizes to RootNode's Props to properly communicate the constrains to Yoga.
Reviewed By: sahrens
Differential Revision: D10387798
fbshipit-source-id: a02ec0a20b3ef28f6230738e5b3a4a2b0b8e0961
Summary: This is the second and the final part of adopting clang-format.
Reviewed By: mdvacca
Differential Revision: D10229624
fbshipit-source-id: d97670b716800ea2488b84bd0aacaf54d8bd2e31
Summary: That should save us some app size kilobytes.
Reviewed By: mdvacca
Differential Revision: D10081499
fbshipit-source-id: 2b950768c609b412f9be332c22b6b1e96657e5ea
Summary: This diff fixes the compilation error: "implicit instantiation of undefined template std::hash" when using TextAttributes in Android
Reviewed By: shergin
Differential Revision: D9849407
fbshipit-source-id: 7fcb94b1d4f7715d8037ecbf302d8f345e99e9fd
Summary: This change drops the year from the copyright headers and the LICENSE file.
Reviewed By: yungsters
Differential Revision: D9727774
fbshipit-source-id: df4fc1e4390733fe774b1a160dd41b4a3d83302a
Summary:
I was watching a classic magnificent talk about modern C++ by Herb Sutter and I was totally sold on double down on using `auto` in our codebase. Surprisingly, 95% of the code base already follows Herb's guidence; I just changed the last 5% to make it consistent.
All those changes must work *exactly* like it was before.
The talk: https://youtu.be/xnqTKD8uD64?t=28m25s
Reviewed By: mdvacca
Differential Revision: D9753301
fbshipit-source-id: 9629aa485a5d6e51806cc96306c297284d4f90b8
Summary:
@public
Voalá, this small change actually implements view flattening. Obviously, it does not work right now because there are no `ShadowNode` classes which implement `isLayoutOnly`.
Surprisingly, correct implementing of `isLayoutOnly` is quite tricky, we will work on this in coming diffs.
Reviewed By: mdvacca
Differential Revision: D9403565
fbshipit-source-id: 1f16f912cb5c6841405a1fc3cf36aec28698c11f
Summary:
@public
We need some another object like ShadowNode (but not ShadowNode) to represent an instance of the component in the mutation instructions. This is
the main motivation for introducing ShadowView.
Why not use ShadowNode? ShadowNode is designed to represent a node in ShadowTree, not be a part of a mutation instruction.
* ShadowNode exposes some APIs that should not be exposed to the mounting layer;
* ShadowNode is an immutable data structure, so we cannot mutate it in some way which can be meaningful for mounting;
* We should not add to ShadowNode any functionality which is needed only for mounting;
* ShadowNode is a bit more heavy object to share that it needs to be; it's exposed (embedded into Mutation) as a `shared_ptr` which is not optimal from the performance perspective;
* Retaining ShadowNode from mounting code can unnecessarily extend its lifetime which can negatively affect memory usage.
Reviewed By: mdvacca
Differential Revision: D9403562
fbshipit-source-id: 72ad81ed918157a62cd3d1a03261f14447649d0b
Summary:
@public
In most cases callsite knows probable index of replacing child node, hence it makes sense to provide this info to `replaceChild` to illuminate O(n) search in most cases.
Reviewed By: mdvacca
Differential Revision: D8814809
fbshipit-source-id: 0edf82878a72260365e2757beb3886ad07c7464d
Summary:
@public
This diff consists of many interdependent changes which support one simple idea: YogaLayoutableShadowNode is now using YGNode children to iterate on them (it previously relied on `ShadowNode::getChildren()`). All other changes are just an unavoidable consequence of that. Hence we don't need to filter child nodes every single time when we do layout anymore! The logic around `clone callback` is also drastically simpler now.
The new approach also implies that `LayoutableShadowNode` and `YogaLayoutableShadowNode` don't use `shared_ptr`s to refer to ShadowNode objects because new relationship does not imply ownership. No more `SharedShadowNode` objects in those two classes.
Reviewed By: mdvacca
Differential Revision: D8796159
fbshipit-source-id: 6f52f92d1826f3eb13b2f8a132c3ea77de155d82
Summary:
@public
Most of them are legit issues which should not be compilable anyways (but Clang tolerates thems).
Reviewed By: mdvacca
Differential Revision: D8655539
fbshipit-source-id: 645729fb9d6a120ce1ab2b07542abcdacd72320d
Summary:
@public
... and we initalize this in Surface.
We need this for requesting images with proper size/pixel-density, setup proper parameters for rasterizing CALayer's and rounding layout metric values.
Then we have to figure out how to wire this up with YGConfig.
Reviewed By: fkgozali
Differential Revision: D8475639
fbshipit-source-id: cec7af581b94efb4595dcf3f232252ce87a1fde3
Summary:
`LayoutableShadowNode.cpp` includes `"LayoutableShadowNode.h"` as well as `<fabric/core/LayoutContext.h>`. In turn, `LayoutContext.h` then includes `<fabric/core/LayoutableShadowNode.h>`. `LayoutContext.h` doesn't actually require `LayoutableShadowNode.h`, but this unnecessary inclusion can cause duplicate definition errors if the two include paths don't map to exactly the same file. This patch removes the unnecessary include.
The CI's build system should cover the testing needed.
[INTERNAL] [MINOR] [fabric] - Remove an unnecessary include in fabric/core/layout.
Closes https://github.com/facebook/react-native/pull/19548
Differential Revision: D8313337
Pulled By: shergin
fbshipit-source-id: 2e01e29ff25131543d9a8601483c2e716c7437be
Summary:
Same as previous one.
Adopting template-generated `convertRawProp` and `debugStringConvertibleItem` functions in `core` module.
Note, to do so we have to change signatures of some conversions functions to make them more overloading-friendly.
Reviewed By: fkgozali
Differential Revision: D7958243
fbshipit-source-id: 500ee420d9aa562ee3c5810ef625e06541eda8fb
Summary:
Same as previous one.
Adopting template-generated `convertRawProp` and `debugStringConvertibleItem` functions in `graphics` module.
Note, to do so we have to change signatures of some conversions functions to make them more overloading-friendly.
Reviewed By: fkgozali
Differential Revision: D7958252
fbshipit-source-id: 0f33a2e6aad60befacee31486acdb9b6114d3e07
Summary:
Apparently, we don't need this functionality in Fabric because we compute mutation instactions during diffing anyways.
But we still need (will need) `LayoutContext` for sure.
Reviewed By: mdvacca
Differential Revision: D7857045
fbshipit-source-id: 4be2744d9abea473ead847f35f698104f94af33d
Summary: RCTParagraphComponentView is a UIView which can render text using TextLayoutManager.
Reviewed By: mdvacca
Differential Revision: D7751853
fbshipit-source-id: e6ee9a0f989cdf6e878390d37dbcf8a11ef90bf4
Summary:
It's more useful and consistent now because:
- We print compound layout metrics from the correct storage (not from Yoga nodes);
- It works fro any kind of layout now (but we still have just one);
- It's much clear and straight-forward.
Reviewed By: fkgozali
Differential Revision: D7607422
fbshipit-source-id: 4c3cd2848e785a7f77c7f591e376d00c7c09ade9
Summary:
The previous name conflicts with the method with same (but with different semantic) name in `ShadowNode` class.
That was bad idea to use same name especially because the different semantic.
Reviewed By: fkgozali
Differential Revision: D7554549
fbshipit-source-id: 0bccbaacd0812f8a26592b2008f15ddb5bc34ebc
Summary:
`enum class` types do not provide default conversion to integers and reguire use typename before value names.
This must prevent bugs like the previous one where we used `Undefined` as a number value.
Reviewed By: fkgozali
Differential Revision: D7554548
fbshipit-source-id: b19379aae48c9aebe03043e08cf3acc712da3cb8
Summary: Quite obvious. We have to check `sealable` flag of the child (not a parent) before mutating it.
Reviewed By: mdvacca
Differential Revision: D7526407
fbshipit-source-id: ce8e0d6446ff7eb23baee9c92f246d5e198fe377
Summary: Slightly new approach: Some non-const methods might not always mutate objects, so sometimes we should call `ensureUnsealed()` only inside conditional branches where we actually mutate an instance.
Reviewed By: fkgozali
Differential Revision: D7467793
fbshipit-source-id: 1b9f229cf6816e54e0df36699a571fdb612d3c3c
Summary:
First, LayoutableShadowNode::cloneAndReplaceChild() is now pure virtual. The default implementation was useless and confusing.
Second, cloneAndReplaceChild() is now fully implemented for ViewShadowNode, so fancy Yoga Concurrent layout *should* work now.
Reviewed By: mdvacca
Differential Revision: D7376352
fbshipit-source-id: 1199a37e64535c8592a2a5480e60139f61d02006
Summary: LayoutableShadowNode defines a unified interface (and set of primitives) essential for laying out shadow nodes.
Reviewed By: fkgozali
Differential Revision: D7230668
fbshipit-source-id: d8c1772d4c3bd1f87c41f7240a39aecebf3696ae
Min ho Kim
David Vacca
Valentin Shergin
empyrical
Joshua Gross
Héctor Ramos
Robert Sayre