This experiment makes sure a ASCollectionView's `rangeController` updates when
a changeset WITH updates is applied. Currently it is possible for nodes
inserted into the preload range to not get preloaded when performing a batch
update.
For example, suppose a collection node has:
- Tuning parameters with a preload range of 1 screenful for the given range
mode.
- Nodes A and B where A is visible and B is off screen.
Currently if node B is deleted and a new node C is inserted in its place, node
C will not get preloaded until the collection node is scrolled. This is because
the preloading mechanism relies on a `setNeedsUpdate` call on the range
controller as part of the `-collectionView:willDisplayCell:forItemAtIndexPath:`
delegate method when the batch update is submitted. However, in the example
outlined above, this sometimes doesn't happen automtically, causing the range
update to be delayed until the next the view scrolls.
* Account for possible inverted transform during hit test
When ASCollectionNode has the `inverted` flag set, a transform gets
set on the cell node. We need to make sure that we account for that
when dealing in the view coordinates.
* Store self.node and self.node.view in local variables for better readability.
* Add a test for hit testing in an inverted ASCollectionNode
- The issues in #1038 are not explained.
- In `ASCollectionViewTests` do not mock every `collectionViewLayout`, only do it for the test that requires it. In addition, call `-stopMocking` when done. OCMock 3.6 found this code using stuff after it should have been.
- 5c42bb4e2f says the layer tests are not typically run, but they are in the project. That diff refers to ASUIViewTests being skipped, but those tests do not exist. So I've just disabled them in this diff. It is not clear how they ever worked.
* [ASDataController] Avoid flushing editing queue before starting data controller pipeline
Step 1 of the pipeline is on main thread and needs pendingMap which was updated by the end of step 1 of the run. And step 1 operates on data source index space. So it should be ok to start it ASAP -- without waiting for any running work on the background editing queue.
One potential race condition after this change is that it's possible for main thread to query the data source (step 1) while the editing queue consumes the last change set (step 3). However, as long as the client's each nodeBlock and the node's layout code capture/reference an individual model object (as opposed to the whole data set) -- which is what clients are supposed to do anyways, then everything should be fine.
The benefit of this diff is that the pipeline will be able to accept many more change sets within a short time window, for example when clients submit a burst of separate small updates.
I tested this diff against our test suite several times and smoke tested it in our code base without any issues.
* Wrap in an experiment
* Enable experiment in tests
* Minor change
* Remove experimental features
* prevent blocking main thread
* remove small content all together as none is the default
* Update ASExperimentalFeatures.h
* Add experiment to skip waiting until all updates of collection/table view are committed in -accessibilityElements
The wait was introduced in #1217 which blocks the main thread until updates are proccessed. We suspect this causes perf regressions accross the app and need to confirm this via an experiment.
* Add option to skip default behavior of ASCellLayoutMode
* Fix unit test
* Fix unit test in another way
* Remove import
* Minor change
* Add ASCellLayoutModeSyncForSmallContent
* Update unit tests
* Remove unnecessary change
* Remove unnecessary changes
* Introduce ASCellLayoutMode
* Some smaller improvements
* Improve logic around _superPerformBatchUpdates:completion:
* Add comment about default values for ASCellLayoutModeNone
* Always call _superReloadData:completion: within UICollectionView
* Add initial range test for ASCellLayoutModeNone
* [License] Simplify the Texture license to be pure Apache 2 (removing ASDK-Licenses)
With permission of the Facebook Open Source team, we are simplifying the Texture
license so that clients can rely on the Apache 2 terms that most of Texture is
already covered by. This means that code originally forked from AsyncDisplayKit
will be re-licensed from "BSD 3-clause + PATENTS v2" to Apache 2 without a
PATENTS file.
After getting confirmation that the updates to these core files look good, we'll
propagate this new license header to all files (in this same PR) and get sign-off
from all parties before landing.
* [License] Update all Texture source files to be pure Apache 2.
* Changelog entry for Apache 2 license update.
* Revert "[License] Update all Texture source files to be pure Apache 2."
This reverts commit ffa0fbbba9.
* [License] Update all Texture source files to be pure Apache 2, maintaining copyrights.
* [License] Update CONTRIBUTING, README, Podspec & Dangerfile.
* Update the dangerfile
* Make a trivial change to test new dangerfile
* Try out the new value with another trivial change
* Add a configuration API to make a unified place for pulling config from clients safely
* Specify properties for delegate
* Finish removing text experiment global enable
* Generate the config file
* Clean up configuration to fix tests
* Work on making it serializable
* Finish it up
* Fix example code
* Update sample project
* Clean up a few things
* Align with new project order
* Make it faster and update license header
* Add an option to specify your config at compile time
* Update another license header
* Add a version field, and bring interface state coalescing into configuration
* Update CA queue code
* Update CATransactionQueue tests
* Turn transaction queue on by default (for now, see comment)
* Update the tests
* Update the tests AGAIN
* Remove unused ordered set
* fix SIMULATE_WEB_RESPONSE not imported #449
* Coalesce interface state updates to ASCATransactionQueue before CATransaction commit.
This will avoid duplicate interface state delegate calls caused by view repeatly added/removed to/from hierarchy during controller animation transition.
* fix tests for new run loop queue
* Support for disabling ASCATransactionQueue
* Fix didExitHierarchy to use ASCATransactionQueue.
* merge range managed and none range managed for didExitHierarchy
* Revert "merge range managed and none range managed for didExitHierarchy"
This reverts commit f807efaa65.
* merge range managed and none range managed for didExitHierarchy
* remove metadata
* abstract queue to impl class methods
* Add tests
* Fix test fail because of shared object.
* guard _pendingInterfaceState access with lock
* name refactor
* Refactor from comments https://github.com/TextureGroup/Texture/pull/788/\#pullrequestreview-94849919
* Apply InterfaceState immediately after ASCATranactionQueue is processed and before next runloop started.
* refactor
* no op to start CI build
* remove unused var and kick off tests
* change lisence
* remove code for weak ref
* add change log and adjust license
* [ASTraitCollection] Add missing properties to ASTraitCollection
* ASTraitCollection now completely reflects UITraitCollection
* Add ASContentSizeCategory enum that corresponds to
UIContentSizeCategory and can be used inside a struct.
* * Remove enum ASContentSizeCategory.
* Use __unsafe_unretained UIContentSizeCategory instead of the enum.
* Added ASPrimitiveTraitCollection lifetime test
* Changes requested at code review:
* Restore one of the ASTraitCollection constructors with a deprecation notice.
* Clean up API by the separation of tvOS-specific interfaces.
* Use [NSString -isEqualToString:] for ASPrimitiveContentSizeCategory equality tests for better readability.
* Encapsulate fallback logic for UIContentSizeCategoryUnspecified.
* Fix failing test
* [ASCollectionNode] Add -isProcessingUpdates and -onDidFinishProcessingUpdates: APIs.
Over time, there have actually been a lot of legitimate uses for an API like this.
In fact, I'm not quite sure what has held us back from adding one!
I believe that at least some portion of -wait calls (even if less than 50%) could be
replaced with -onDidFinishProcessingUpdates:, which could potentially improve the
performance of applications using -wait by a significant amount.
Please take a close look at implementation correctness. Although I'm in a bit of a
rush, I'm aiming to make this properly documented and added a basic test -- but it
could certainly use some more detailed testing as a followup.
* [ASCollectionNode] Improvements to the implementation of -isProcessingUpdates and -onDidFinishProcessingUpdates:
* Add lock to ASMainSerialQueue count method.
* [ASTableNode] Implement -isProcessingUpdates and -onDidFinishProcessingUpdates:. Rename -waitUntil to consistent naming.
* Add _ASCollectionReusableView container for ASCollectionNode supplementary nodes with applyLayoutAttributes support
• Adds support for -[ASCellNode applyLayoutAttributes:] to supplementary nodes
* Ensure _ASCollectionReusableView has layoutAttributes if the collection view doesn’t set them
* Use correct layoutAttributes accessor for supplementary elements
* Add unit test to test trait collection changes occur during updates are handles correctly
* Remove handling code in ASDataController:updateWithChangeSet. Previous test should fail
* Correctly handle trait collection changes that occur mid-updates
- Currently, when there is a new trait collection, we correctly propagate it to all visible elements. However, since the propagating block is executed on main thread immediately without waiting for the background editing queue of ASDataController, not all elements are updated.
- Then to fix that, we updated ASDataController to handle these changes inside updateWithChangeSet. This works, but it doesn’t address the underlying issue.
- We now delegate the propagating task to ASDataController which schedule a block to its main serial queue after waiting for its background editing queue.
rqueue
Ben Dolman
Greg Bolsinga
dmaclach
vovasty
Huy Nguyen
ernestmama
Huy Nguyen
Michael Schneider
appleguy
Adlai Holler
Max Wang
Yevgen Pogribnyi
Garrett Moon
Phil Larson
Adlai Holler