* Make display node, layout spec, and style conform to NSLocking so that users/subclasses can access their locks
* Update the changelog
* Align slashes
* Put it back, when we're in ASDisplayNode
* Go a little further
* Put back the changes I didn't mean to commit
* Kick the CI
* Fix yoga build
* Put back non-locking change
* Address comments from Scott
* [ASDisplayNode layout] Fix an issue that causes a node's pending layout to not be applied
- Since the implementation of layout version (#428), if a node's pending and calculated layouts have the same current version as well as the same constrained size, the 2 layouts are considered equal and can be used interchangeably. A layout version check between the 2 layouts was added in #695. This PR adds a missing constrained size check.
- If the pending layout has the same version but a different constrained size compare to the calculated layout's, we can assume that the pending layout is newer and should be preferred over the calculated one. That is because layout operations always register their new layout as pending, which then (immediately or eventually) get applied to the node as calculated layout.
Before:
- Even if a pending layout was applied before, it'll be unnecessarily applied again in next layout passes and cause `-calculatedLayoutDidChange` being called multiple times.
After:
- If a pending layout was applied, the calculated layout will not be ignored but reused, if possible, in next layout passes.
Test plan: testSetNeedsLayoutAndNormalLayoutPass in #424.
* Be more aggressive at invalidating layouts during transitions, add a debug method, fix some build errors when verbose logging
* Add a changelog entry
* Invalidate the calculated layout transitioning using the same size range
- It's possible that -transitionLayoutWithSizeRange: can be called with the same size range used for previous layout passes. In that case, it's necessary to invalidate the current layout to avoid it being reused later on in the process.
* Fix CHANGELOG
* Fix infinite layout loop
- The problem will occur if a node does either of the followings:
1. Keeps using a stale pending layout over a calculated layout
2. Doesn't update the next layout's version after calling _setNeedsLayoutFromAbove.
* Update CHANGELOG
I believe this check is supposed to be here. Unit tests pass with it in place.
Without it, calling layoutThatFits: (as ASDataController does) and then calling
it again later (as ASCollectionNode does when answering the sizeForItem: call)
will recompute the layout, potentially on main.
This seems to have more of an impact / benefit for Yoga layouts, but I don't think
its benefit is exclusive to them.
This ensures that measure funcs are not set for container / empty spacer
nodes, because Yoga has more internal capabilities than layoutThatFits:
knows about.
Avoid need for the main layout pass to directly call setup for measure
funcs, by making it an implicit part of .yogaLayoutInProgress =.
Tear down the measure func after the layout pass to avoid retain cycle.
This has one important benefit: fixing the stretching behavior of spacer nodes.
In addition, it should help efficiency of Yoga and certainly minimize calls
to layoutThatFits:.
Next up for Yoga is a mostly-red diff, deleting the non-Contiguous code branches.
* [ASTraitCollection] Convert ASPrimitiveTraitCollection from lock to atomic.
This resolves a deadlock case: https://github.com/TextureGroup/Texture/issues/353
* [ASTraitCollection] Use assignment operator instead of .store() for C++ atomic.
* Small changes required by the layout debugger
- `ASDisplayNode` can be told to not flatten its layout immediately but later on. The unflattened layout is also stored in a separate property. It's needed for inspecting not only display nodes but also layout specs used to compute a layout tree.
- `ASLayout` can be told to always retain its sublayout elements. This is needed especially for layout specs since they are usually not retained after an ASLayout was computed.
* Update CHANGELOG
* Address comments
It is rare that this code has any effect, but I've discovered a case in which it occurs.
This task tracks moving this code to a DEBUG-only assertion: https://github.com/TextureGroup/Texture/issues/335
