Summary:
This diff introduces new, little bit sophisticated round-to-pixel-grid algorithm.
**Motivation:**
Previous simple and straightforward solution works in most cases but sometimes produce the not-so-great result. A while ago Nick Lockwood described this problem and proposed the solution in RN's RCTShadowView class:
For example, say you have the following structure:
// +--------+---------+--------+
// | |+-------+| |
// | || || |
// | |+-------+| |
// +--------+---------+--------+
Say the screen width is 320 pts so the three big views will get the following x bounds from our layout system:
{0, 106.667}, {106.667, 213.333}, {213.333, 320}
Assuming screen scale is 2, these numbers must be rounded to the nearest 0.5 to fit the pixel grid:
{0, 106.5}, {106.5, 213.5}, {213.5, 320}
You'll notice that the three widths are 106.5, 107, 106.5.
This is great for the parent views but it gets trickier when we consider rounding for the subview. When we go to round the bounds for the subview in the middle, it's relative bounds are {0, 106.667} which gets rounded to {0, 106.5}. This will cause the subview to be one pixel smaller than it should be. This is why we need to pass in the absolute position in order to do the rounding relative to the screen's grid rather than the view's grid. After passing in the absolutePosition of {106.667, y}, we do the following calculations:
absoluteLeft = round(absolutePosition.x + viewPosition.left) = round(106.667 + 0) = 106.5
absoluteRight = round(absolutePosition.x + viewPosition.left + viewSize.width) + round(106.667 + 0 + 106.667) = 213.5
width = 213.5 - 106.5 = 107
You'll notice that this is the same width we calculated for the parent view because we've taken its position into account.
I believe this is awesome. I also believe that we have to decouple this logic from RN and put it into awesome Yoga. So I did it in this diff.
**Fun fact:**
The original implementation of this algorithm in RN had (and still have) a bug, which was found by Dustin dshahidehpour and fixed in D4133643. Therefore that diff was unlanded because it broke something unrelated inside RN text engine. I will fix that problem in RN later.
**Why do we need to change test methodology?**
Because the way we receive layout metrics from Chrome browser actually directly related to rounding problem. Previously we used `offsetHeight` and `offsetWidth` properties of the DOM node, which contain naively rounded values from `computedStyle` or `getBoundingClientRect`. (Which is we are trying to fix!) So, I added the new function that computes node size using two-step-rounding approach, conceptually similar to one that implemented in Yoga. Note: Chrome browser performs rounding layout as part of rendering process and actual values that can ve computed by counting actual pixel are different from these natively rounded ones.
**Why do some tests now have different desired values?**
These changes actually prove that my approach is correct and more useful for actual view rendering goals. So, let's take a look at test with changed values `rounding_fractial_input_3`:
Previously: 64+25+24=114 (Incorrect!)
Now: 65+24+25=114 (Correct!)
Previously: 64+25+24=114 (Incorrect!)
Now: 65+24+25=114 (Correct!)
Reviewed By: emilsjolander
Differential Revision: D4941266
fbshipit-source-id: 07500f5cc93c628219500e9e07291438e9d5d36c
Summary:
The following PR fixes the tests used in the javascript port (it modifies gentest.rb).
These changes don't yet pass, it seems something is segfaulting somewhere. I have to check if it comes from nbind, the yoga library, or the node bridge itself. There's also some fails on the browser build, but it might be the same issue.
Closes https://github.com/facebook/yoga/pull/487
Reviewed By: emilsjolander
Differential Revision: D4778870
Pulled By: astreet
fbshipit-source-id: 936fbca564ec89738c78e50c4402c53eb6867dec
Summary:
Move configuration to new ```YGConfig``` and pass them down to CalculateLayout. See #418 .
Adds ```YGConfigNew()``` + ```YGConfigFree```, and changed ```YGSetExperimentalFeatureEnabled``` to use the config.
New function for calculation is ```YGNodeCalculateLayoutWithConfig```.
Closes https://github.com/facebook/yoga/pull/432
Reviewed By: astreet
Differential Revision: D4611359
Pulled By: emilsjolander
fbshipit-source-id: a1332f0e1b21cec02129dd021ee57408449e10b0
Summary:
- As mentioned in the title, this PR adds Javascript support to Yoga. Two different builds are included in this PR thanks to [nbind](https://github.com/charto/nbind), which conveniently allow to target both Node.js' native addons and browser environments via asmjs with approximately the same codebase. That should solve #215.
- All tests successfully pass on both codepaths. You can run `yarn test:all` inside the `javascript` directory to test it.
- Because of a bug in nbind, the [following PR](https://github.com/charto/nbind/pull/57) needs to be merged and a new version released before this one can be safely merged as well.
- I had to use `double` types instead of `float` in the C++ bindings because of an Emscripten [bug](https://github.com/kripken/emscripten/issues/3592) where symbols aren't correctly exported when using floats.
- There's some tweaks to do before this PR is 100% ready to merge, but I wanted to have your opinion first. What do you think of this?
---
To do:
- [x] Ensure th
Closes https://github.com/facebook/yoga/pull/304
Reviewed By: mikearmstrong001
Differential Revision: D4375187
Pulled By: emilsjolander
fbshipit-source-id: 47248558a9506b7c512b5ef281cd12fe1a60cab7
