8f6a96adbc added a test in isDimDefined that checks if `value > 0.0`, but unfortunately, it did not faithfully port the JavaScript version which is `value >= 0.0`. Sadly, no test covered this so it went unnoticed.
It turns the spacing resolution in Java is fairly expensive right now
because it doesn't a bunch of unnecessary checks in the array,
especially when the Spacing instance doesn't have any values set on it.
This diff changes Spacing to store the state of the defined values in a
bitwise flag so that padding/border/margin queries are a lot faster
during layout calculations. This gives us as extra 20% performance win
in my local benchmarks on Android
Unfortunately, Java doesn't have any build-time inlining solution and
method invocations do have a big performance impact on Android. This
changes Java's transpiler to inline almost all internal methods at build
time. This gives us a 30% performance win in my local benchmarks.
There's a drawback from moving code to the transpiler but I think this
is worth it (given the massive perf wins here) and the inlined methods
are fairly simple.
Change the initial line loop to opportunistically position children in
the in container with simple stacking params i.e. vertical/horizontal
stacking on non-flexible STRETCH/FLEX_START aligned. This allows us to
skip the main and cross axis loops (Loop C and D, respectively)
partially and even completely in many common scenarios.
In my benchamrks, this gives us about ~15% performance win in many
setups.
We were traversing all children to only perform calculations/changes to
flexible children in order to avoid new allocations during layout. This
diff ensures we only visit flexible children during layout calculations
if any are present. We accomplish this by keeping a private linked list
of flexible children.
There's no need to go through all absolute children at the end of the
layout calculation if the node at hand doesn't have any. This also
ensures only absolutely positioned children are traversed in the final
loop.
There's no need to go through all children before starting the main line loop
as we'll visit all children in the former loop anyway. This diff merges the
pre-fill loop into the main line one to avoid an extraneous traversal on the
node's children.
There's no need to set the trailing position on left-to-right layouts
as the nodes will already have what we need (x, y, width, and height).
This means we still have an extra cost for reversed layout directions
but they are not as common as LTR ones.
Store immutable values from the node being laid out to avoid unnecessary
method invocations during layout calculation. This gives us a 3%-5%
performance boost in my benchmarks on Android.
Method invocations are not entirely free on Android. Change the
generated Java code to use the same array-based approach used in
JS and C to compute dimensions, positions, etc instead of relying
too heavily on method invovations. As a bonus, the Java transpiler
becomes a lot simpler because the code is more analogous to the C
counterpart.
In my local benchmarks this change gives us a major performance
boost on Android (between 15% and 30%) depending on the device
and the runtime (Dalvik|Art).
Previously two modules were defined, Layout.js, which is the internal implementation, and main.js, which depended on Layout.js and performed the fill / extract functionality required for a public JavaScript API.
This simplifies the implementation by just exposing a single UMD module by directly including Layout.js within the module wrapper.
Fixes#103
