Summary: #pragma once is widely supported and is a lot harder to get wrong than #ifdef include guards.
Reviewed By: lucasr
Differential Revision: D3648895
fbshipit-source-id: faf42cda82764adaf41cf3f3f9109d48aea203fe
Summary: Java instructions were missing from the readme. Add a quick note about how to run tests in java.
Reviewed By: lucasr
Differential Revision: D3648981
fbshipit-source-id: d9009a60bb1bb0837722f914981ef4e31f0adb68
Summary: stdint.h defines the modern standard c types which have a fixed memory size. This makes the program run more predictably as well as removing the need to ugly double work types such as `unsigned int` or `long long`.
Reviewed By: lucasr
Differential Revision: D3649096
fbshipit-source-id: dc9fc8861c3106494c5d00d6ac337da50a4c945b
Summary: Implement some very basic benchmarking infra. We need benchmarks in css-layout and I want to add something now so that others have the option to follow an example when implementing a benchmark.
Reviewed By: lucasr
Differential Revision: D3648889
fbshipit-source-id: 60b93c6e5ed027a37195a9a5d86e681e3e79a5b9
Summary: This moves the api in line with the java api. hasNewLayout makes for sense than shouldUpdate because the API is not telling css layout to update but is instead just a marker for the user of the API to know if there has been a new layout since last time it checked.
Reviewed By: majak
Differential Revision: D3613695
fbshipit-source-id: 4e16e8d4de90660a09d6e1d3a43c6c5e89349993
Summary:
@public The make current RCTShadowView support RTL layout.
1 Change all left/right to start/end for margin, padding, boarder and position
2 Calculate position in the same way as margin, padding and boarder
Reviewed By: fkgozali
Differential Revision: D3619292
fbshipit-source-id: eaaa6faeee93c964d59bb6f498d89effc09ed567
Summary: @public The new CSSLayout have a wrong calculate for the getRelativePosition. So use the getLeadingPosition will get 0 instead of return undefined. Fix it with using isLeadingPosDefined.
Reviewed By: fkgozali
Differential Revision: D3640799
fbshipit-source-id: 50d3bd2ea4c0d8bf96ba34297425ba269b0535cd
Summary: The test case CSSLayoutTest/test_layout_node_with_bottom has some problem. I can't find a way to fix it without get the screen size. I decided to remove it first. If we could find a better way to right this test case. We can add it again.
Reviewed By: fkgozali
Differential Revision: D3629662
fbshipit-source-id: 303f81a74919e5d3bf037e2809e1345a554a7009
Summary:
@public The current CSSLayout can't support RTL because wrong calculation for absolute position.
This change is mainly to fix the issue: https://github.com/facebook/css-layout/issues/197
Three main problems I fixed:
1. Calculate the position in the same way as margin, boarder, and padding. So that to fix the absolute problem.
2. Fix one wrong calculation for leading value when we only know the trailing value. It was hard code for the LTR situation. Now I changed it to depends on the main Axis.
3. Expose getter and setter function for RN to read layout direction and start/end position value.
Reviewed By: fkgozali
Differential Revision: D3616949
fbshipit-source-id: ae7a47cc0a5d02b42b95f87232be51ab144056d9
Summary: The test case CSSLayoutTest/test_layout_node_with_bottom has some problem. I can't find a way to fix it without get the screen size. I decided to remove it first. If we could find a better way to right this test case. We can add it again.
Reviewed By: fkgozali
Differential Revision: D3629662
fbshipit-source-id: 62d6cd3827d20ae670af55d1c072bd9645a701b9
Summary: Update readme with info about building and github markdown syntax
Differential Revision: D3613284
fbshipit-source-id: 1f57009ccf02a48fe100f675ce08503e15cb6c22
We already did this optimization when there wasn't any
available horizontal space. Now we're covering the
vertical space case as well.
This optimization assumes that, for a node with a
measure function, if there isn't any available
horizontal or vertical space, then we don't need to
measure the node and can assume that the node is 0x0.
Introduced heuristics that enable css-layout to avoid
calling measure functions under a number of conditions.
This enables us to save time by skipping unnecessary
measurements.
We found a case where a flexible item with a max width that was supposed
to be centered was positioned in the wrong location.
The problem was with our 2 pass approach for sizing flexible items with
a min/max width/height. Items sized in the first pass were being double
counted when calculating the remainingFreeSpace. Specifically, their
sizes were being subtracted from remainingFreeSpace in both the first
and second passes.
I also noticed a second unrelated bug. We weren't correctly calculating
deltaFreeSpace in the first pass. When calculating deltaFreeSpace, we
need to take into account the flex basis like we do in the second pass.
Consequently, in the first pass I changed this:
deltaFreeSpace -= boundMainSize;
To this:
deltaFreeSpace -= boundMainSize - childFlexBasis;
The problem there was that we'd end up double counting childFlexBasis
in the remainingFreeSpace.
The primary goals of this change are:
- Better conformance to the W3C flexbox standard (https://www.w3.org/TR/css-flexbox-1/)
and a clear articulation of the areas where it deviates from the spec.
- Support for flex-shrink.
- Conformance with layout effects of "overflow: hidden".
Specifically, here are the limitations of this implementation as compared to the W3C
flexbox standard (this is also documented in Layout.js):
- Display property is always assumed to be 'flex' except for Text nodes, which
are assumed to be 'inline-flex'.
- The 'zIndex' property (or any form of z ordering) is not supported. Nodes are
stacked in document order.
- The 'order' property is not supported. The order of flex items is always defined
by document order.
- The 'visibility' property is always assumed to be 'visible'. Values of 'collapse'
and 'hidden' are not supported.
- The 'wrap' property supports only 'nowrap' (which is the default) or 'wrap'. The
rarely-used 'wrap-reverse' is not supported.
- Rather than allowing arbitrary combinations of flexGrow, flexShrink and
flexBasis, this algorithm supports only the three most common combinations:
- flex: 0 is equiavlent to flex: 0 0 auto
- flex: n (where n is a positive value) is equivalent to flex: n 0 0
- flex: -1 (or any negative value) is equivalent to flex: 0 1 auto
- Margins cannot be specified as 'auto'. They must be specified in terms of pixel
values, and the default value is 0.
- The 'baseline' value is not supported for alignItems and alignSelf properties.
- Values of width, maxWidth, minWidth, height, maxHeight and minHeight must be
specified as pixel values, not as percentages.
- There is no support for calculation of dimensions based on intrinsic aspect ratios
(e.g. images).
- There is no support for forced breaks.
- It does not support vertical inline directions (top-to-bottom or bottom-to-top text).
And here is how the implementation deviates from the standard (this is also documented in
Layout.js):
- Section 4.5 of the spec indicates that all flex items have a default minimum
main size. For text blocks, for example, this is the width of the widest word.
Calculating the minimum width is expensive, so we forego it and assume a default
minimum main size of 0.
- Min/Max sizes in the main axis are not honored when resolving flexible lengths.
- The spec indicates that the default value for 'flexDirection' is 'row', but
the algorithm below assumes a default of 'column'.
