* [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
`[NSAttributedString enumerateAttribute:inRange:options:usingBlock]` can be called multiple times with a value of nil. The current logic didn't consider this to find out if a links is present within the attributed string.
After #1396, some view-backed nodes in our app stop responding to tap events. I tracked it down to [this change](https://github.com/TextureGroup/Texture/pull/1396/files#diff-7fbc7d84a259cbfbee7546a5310dddcfR162) which suggests that the order of execution matters.
This diff attempts to fix the issue by restoring the previous call order where `__enterHierarchy` and `__exitHierarchy` are driven by `_ASDisplayView`'s `-willMoveToWindow:` and `-didMoveToWindow` if the node is view-backed. Layer-backed nodes will still call `__enterHierarchy`/`__exitHierarchy` when they get `kCAOnOrderIn`/`kCAOnOrderOut`.
This maintains the layer-action support introduced in #1396.
* [Dev docs] Node Lifecycle
Here is my draft on a new documentation aims at people interested in learning about technical details of the lifecycle of ASDisplayNode, as well as its interface and loading states. Hopefully it'd be useful for others who want to ramp up and hopefully start contributing to the framework.
Let me know if there are other topics I should cover, or anything I should explain more/dig deeper, or something that is wrong/no longer valid (imposter syndrome much!). Cheers!
* Update node-lifecycle.md
* Address comments
* Improve Accessibility Implementation
- Fixes calculations for accessibilityFrame of ASAccessibilityCustomAction and ASAccessibilityElement
- Fix crash for accessibility elements within layer backed nodes
- Fix accessibility action label updating after other actions change the accessibility label of the corresponding node
* Address comments
* Add support for basic ASTextNode2 link highlighting
* Add approach to fix line highlighting
* Enable proper highlighting for first row
* Fix snapshot highlighting test for ASTextNode2
* Update screenshot again
* Address comments
* Remove the text rendering experiment. It decreased rendering speeds at a negligible improvement to OOMs.
* Adopt new ASGraphicsCreateImageWithOptions API
* ASSignpost: Add support for the os_signpost API
- Removes support for colored intervals. These weren't really useful and they aren't part of the signpost api.
- Fixes an issue with range controller interval logging.
- Adds an interval for interface orientation changes.
* Rename
* Support Xcode 9
* Commentary
Group the BOOLs together, since there are only 4 (and there are no other auto-generated ivars that are < 64 bits) this is sufficient and keeps the properties `atomic`.
Revert "Ensure ASControlMode properties lock before accessing their ivars (#1476)"
This reverts commit ce1e1956f4.
Revert "Make sure all ASDisplayNode properties have backing ivars for consistency. (#1475)"
This reverts commit d6061f4390.
- Except the unused property `interfaceStateSuspended` is still removed (this is a memory saver).
* Shrink ASImageNode by .6% and ASNetworkImageNode by 2.2%
ASImageNode goes from 1384 to 1376. ASNetworkImageNode goes from 1496 to 1464.
These objects accumulate in the heap, so reducing their size will allow more to accumulate before memory warnings.
Group the `BOOL`s into a struct. Shrink the various stored `enum`s to fit the size of their contents. Move the ivars around so that the smaller `enum` are near eachother and the bitfield struct.
* add comments as requested in garrett's review.
* access ivar directly since already locked as suggested in review.
Running on iPhone SE Simulator:
ASPagerNode 1240 to 1232 bytes .7% reduction
ASScrollNode 1104 to 1096 bytes .7% reduction
- make ASScrollNode smaller by shrinking ASScrollDirection, which requires a change to ASRangeController
- shrink ASPagerNode by declaring the BOOL next to the struct
Running in iPhone SE Simulator:
- ASTextNode: 1360 to 1352 bytes .6% reduction
- ASTextNode2: 1360 to 1304 bytes 4.3% redction
Shrink stored enum sizes. Group BOOLs near these smaller enums. Override -usingExperiment to return constant instead of never set, but allocated ivar.
Button: 1312 to 1288 bytes, running on iPhone SE simulator. 1.9% reduction.
Shrink the enums it stores, and place them next to each other (along with a BOOL) to reduce instance size.
* Shrink ASDisplayNode from 1088 to 976 bytes, reduction of 11.48%
These objects accumulate in the heap, so reducing their size will allow more to accumulate before memory warnings.
Group the `BOOL`s into a struct. Shrink the various stored `enum`s to fit the size of their contents. Move the ivars around so that the smaller `enum` are near eachother and the bitfield struct.
* Forgot to bit-field-ify placeholderEnable; new small size is 968, old size is 1072 (measured consistentlyl on iPhoneSE simulator). 10.74% reduction.
* Shrink _ASPendingState from 824 to 808 bytes, reduction of ~2%
These objects accumulate in the heap, so reducing their size will allow more to accumulate before memory warnings.
Shrink ASPendingState BOOLs. Use unsigned int for these bitfields for clarity. Separate from `_flags` as that struct is compared to `0` for testing. The `_boolFlags` struct is just storing other `BOOL`s.
* rename struct fields as suggested in garret's review.
* Shrink _ASCollectionPendingState from 144 to 128 bytes, a 12.5% reduction
These objects accumulate in the heap, so reducing their size will allow more to accumulate before memory warnings.
Group the `BOOL`s into a struct. Shrink the various stored `enum`s to fit the size of their contents. Move the ivars around so that the smaller `enum` are near eachother and the bitfield struct.
* address review comments. move enums out. add comment. rename struct to _flags
* fix a missing rename