With these changes, I'd also like to propose that we move ASNodeController
out of Beta (renaming the files without +Beta). Let me know what you think!
Because we don't support ASNodeController directly in ASCV / ASTV, it is still
important to allow flipping the ownership in certain cases (in particular, for
root CellNodeController objects that should follow the lifecycle of the
ASCellNode rather than owning the ASCellNode).
* Be more aggressive at invalidating layouts during transitions, add a debug method, fix some build errors when verbose logging
* Add a changelog entry
* 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
This makes it much easier to use the ASCoreAnimationExtras method which offers by
far the most efficient way to display a stretchable image.
In the future, we should move that function to UIImage+ASConvenience or another
header where it can be more easily found and enjoyed!
This was originally added for ASCollectionNode and ASTableNode preloading to work
as intended when nested inside of another ASRangeController-powered node. Indeed,
it is still necessary to trigger layout on these UIKit-backed components in order
for their own ASRangeControllers to start preparing content within them.
However, unlike the comment suggests, it is *not* necessary to do this for image
nodes. ASNetworkImageNode has only one .URL, and does not use the .bounds or
.calculatedLayout at all during loading. Even the ASMultiplexImageNode does not
use the .bounds, and the ASMapNode uses .calculatedLayout instead of .bounds.
This change has important performance benefits. In particular, it avoids
layouts that would occur on the main thread, often including text sizing,
and also can result in redundant layout passes (even during a layout pass that
triggers a node to enter the preload range, it may force its own layout early).
It would be great to test this change with Pinterest to confirm its safety, but
based on a full audit of the framework codebase, the only possibility that I
see for a regression is if app implementations of -didEnterPreloadState make
direct use of .bounds instead of .calculatedLayout (which is easy to fix).
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.
* [Yoga] Rewrite YOGA_TREE_CONTIGUOUS mode with support for mixing with ASLayoutSpec.
After experimentation with the ASYogaLayoutSpec (or non-contiguous) approach to
integrating Yoga, test results and feedback from the authors of Yoga have shown
that this approach can't be made completely correct,
There are issues with some of the features required to represent Web-style
flexbox; in particular: padding, margins, and border handling have varience.
This diff is a first step towards a truly correct and elegant implementation of
Yoga integration with Texture. In addition to reducing the footprint of
the integration, which is an explicit goal of work at this stage, these changes
already support improved behavior - including mixing between ASLayoutSpecs
even as subnodes of Yoga layout-driven nodes, in addition to above them. Yoga
may be used for any set of nodes.
Because Yoga usage is limited at this time, it's safe to merge this diff and
further improvements will be refinements in this direction.
* [ASDKgram] Add Yoga layout implementation for PhotoCellNode.
* [Yoga] Final fixes for the upgraded implementation of the Contiguous layout mode.
* [Yoga] Add CHANGELOG.md entry and fix for Yoga rounding to screen scale.
* [Yoga] Minor cleanup to remove old comments and generalize utility methods.
* 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
* [Yoga] Implement ASYogaLayoutSpec, an experimental alternative to full-tree integration.
This approach allows us to avoid any ASDisplayNode.mm integration points.
However, it is not yet proven to be possible to achieve correctness with this approach.
The entry point (to start calculating), and the measurement function inputs, lack
the full expressiveness of ASSizeRange; we need to make sure that workarounds like
using style.minSize are successful in simulating the behavior of a full Yoga tree.
* [Yoga] Fix file comments, move towards <ASLayoutElement> support.
* [Yoga] Important fix for simplified, non-contiguous Yoga integration.
* [Yoga] Complete implementation of manual memory management (__bridge_transfer, YGNodeFree)
* [ASDisplayNode] Convert isSynchronous to an Objective-C atomic BOOL.
This reduces lock contention, and should also fix a very rarely seen deadlock.
* [ASDisplayNode] Implement a std::atomic-based flag system for superb performance
Although Objective-C atomics are equally fast, or better that std::atomic when
access through method calls, for the most intense use cases it is best to avoid
method calls entirely.
In ASDisplayNode, we could benefit significantly from avoiding both method calls
(already true today) but also avoid locking the mutex, for both CPU and contention
gains.
There will still be many methods that need locking for transactional
consistency - however, there are currently dozens of accessor methods that could
avoid frequent lock / unlock cycles with use of atomics, and other usages of the
ivars directly where locking could be delayed until after early-return conditions
are checked and passed.
* Add a thread-safe layoutIfNeeded implementation to ASDisplayNode
* Trigger a layout pass when a display node enters preload state
- This ensures that all the subnodes have the correct size to preload their content.
* ASCollectionNode to trigger its initial data load when it enters preload state
* Minor change in _ASCollectionViewCell
* Layout sublayouts before dispatch to main for subclass hooks
* Update comments
* Don't wait until updates are committed when the collection node enters display state
* Same deal for table node
* Explain the layout trigger in ASDisplayNode
* Introduce ASCollectionViewLayout
- `ASCollectionViewLayout` is an async `UICollectionViewLayout` that encapsulates its layout calculation logic into a separate thread-safe object which can be used ahead of time and/or on multiple threads.
- `ASDataController` now can prepare for a new layout resulted from a change set before `ASCollectionView` even knows about it. By the time the change set it ready to be consumed by `ASCollectionView`, its new layout is also ready.
- New `ASCollectionViewLayoutCalculating` protocol that is simple and generic enough that many types of calculators can be built on top. `ASCollectionViewLayoutSpecCalculator` conforms to `ASCollectionViewLayoutCalculating` protocol and can be backed by any layout spec (e.g `ASStackLayoutSpec`, `PIMasonryLayoutSpec`, etc). We can even build a `ASCollectionViewLayoutYogaCalculator` that uses Yoga internally.
- A built-in `ASCollectionViewFlowLayoutCalculator` that is a subclass of `ASCollectionViewLayoutSpecCalculator` and uses a multi-threaded multi-line `ASStackLayoutSpec` internally. The result is a performant and thread-safe flow layout calculator.
- Finally, `ASCollectionViewLayout` can be subclassed to handle a specific type of calculator with optimizations implemented based on the knowledge of such calculator. For example, `ASCollectionViewFlowLayout` can have a highly optimized implementation of `-layoutAttributesForElementsInRect:`.
Protocolize layout calculator providing and consuming
Add flex wrap documentation
Add a `multithreaded` flag to ASStackLayoutSpec that forces it to dispatch even if it's off main
- Update ASCollectionViewFlowLayoutSpecCalculator to use that flag.
Minor change in ASCollectionViewLayout
Implement Mosaic layout calculator
Minor change
Fix project file
Rename and fix project file
Skip fetching constrained size only if a layout calculator is available
Update examples/ASCollectionView
Remove unnecessary change in ASTableView
Address comments
Rename collection view calculator protocols
Minor changes after rebasing with master
Add ASLegacyCollectionLayoutCalculator for backward compatibility
Remove ASCollectionLayoutSpecCalculator
Remove ASLegacyCollectionLayoutCalculator
Introduce ASCollectionLayout
- A wrapper object that contains content size and an element to rect table.
- Collection layout calculators to return this new object instead of an ASLayout.
Before adding a content cache
Finishing hooking up ASCollectionLayoutDataSource to ASCollectionNode
Stash
Finish ASCollectionLayout
Rough impl of ASCollectionFlowLayout
Revert changes in CustomCollectionView example
Move ASRectTable back to Private
* Rename ASCollectionContentAttributes to ASCollectionLayoutState
* Address other comments
* Introduce ASCollectionLayoutDelegate and make ASCollectionLayout private
* Address comments
* API tweaks:
- Replace `-layoutContextWithElementMap:` in ASCollectionLayoutDelegate with `-additionalInfoForLayoutWithElements:`. The returned object is then stored in ASCollectionLayoutContext for later lookups.
- ASCollectionLayoutContext has no public initializer.
- ASDataControllerLayoutDelegate no longer requires a context of type ASCollectionLayoutContext but simply an `id`. This helps decouple ASDataController and ASCollectionLayout.
- Rename `elementMap` to `elements`.
- Rename `visibleMap` to `visibleElements`.
- Other minor changes.
* Rename ASCGSizeHash to ASHashFromCGSize
* Make sure to call super in -[ASCollectionLayout prepareLayout]
* Update example/ASCollectionView to use ASCollectionFlowLayoutDelegate
* Remove unnecessary change
- It's not safe to hold the lock of a supernode and:
- Edit states of its subnodes
- Call subclass hooks
- Run completion block
- Run animation, which can trigger layout passes on subnodes, especially if one of them is a collection view.
We have to check in this case if the supernode of the subnode is indeed the _node that executes a layout transition. It can happen that a node already did a layout transition and added this subnode, in this case the subnode would would be removed from the new node instead of _node.
- Before this commit:
- Bridged properties are accessed to construct a recursive description without considering thread affinity.
- We have multiple methods that does the same thing: generates a debug description.
- After this commit:
- Bridged properties are accessed without triggering thread affinity assertions.
- We have only one method that provides debug description of a node. It is then used to construct a recursive description.
