traitCollectionDidChange isn't necessarily called on Main, but our self.backgroundColor property access must be done on main once the view is loaded.
I originally opted to use self.backgroundColor rather than _backgroundColor in #1674, but I think we should use the ivar here. This could get out-of-sync if someone modified the UIView's background color instead of updating the node, but I think that's unlikely, so we should be safe to use the ivar here.
- Address various issues with tint color on text nodes
- Avoid accessing `self.tintColor` off-main since this will trigger an
assertion and might be undefined behavior
- Trigger setNeedsDisplay in cases of hierarchy change and
tintColorDidChange in ASButtonNode, ASTextNode{1,2}
- Fix bug in _ASTableViewCell where we were overwriting the tint color
instead of inheriting the correct value
- Add tests for new logic in changing hierarchy
* This PR addresses an issue I raised with #1673 where the clipping corner layer doesn't get re-rendered when going from a dark to light user interface style. The fix is to add code in the `-asyncTraitCollectionDidChangeWithPreviousTraitCollection:` method that calls through to `-_updateClipCornerLayerContentsWithRadius:backgroundColor:` if the user interface style changes.
I've also added snapshot tests to verify that using clipping corners with a dynamic background color updates when the user interface style changes.
* ASImageNode tintColor improvements.
When ASImageNodes changes tintColor or enters the hierarchy, ensure -setNeedsDisplay is called if the image is templated.
Add unit tests to ensure this behavior works.
* Node TintColor Tweaks
- If the tint color changes, be sure to call -setNeedsDisplay on the view.
- Explictly declare tintColor ivar and getter method.
- If the tintColor is the same as the existing one, early-exit.
- Use the ivar and not the property when setting the tintColor, just as is done for background color.
- Add tests (for non iOS13 and iOS13) that the tintColor will call -setNeedsDisplay
- Backfill tests to document/verify the tintColor behavior on a node.
There is a potential dealloc race condition that can occur when attempting to perform work with image asset out of the main thread. Moving that work into the image node draw loop if necessary
- Fix availability warnings for usage of userInterfaceLevel
- Deprecate `asyncTraitCollectionDidChange` in favor of the new method
- Remove old compiler warning flag added for Xcode 9 building
- Access `textColorFollowsTintColor` with a locked scope
* Fix issue where UIGraphicsRendererFormat is mutated
As part of https://github.com/TextureGroup/Texture/pull/1629, we use the
preferred or default UIGraphicsRendererFormat. This was pointing to a
static variable which content scale was mutated across several graphic
render passes and lead to pixelated views.
* Update reference images with iOS 10.3
To preserve dynamic color capabilities for layer-backed
nodes, we need to track backgroundColor as a UIColor. In layer backed nodes we lose the dynamic color logic since we
extract a CGColor from the UIColor applied to ASDisplayNode. With this
change we can respond to changes in UITraitCollection.userInterfaceStyle
for backgroundColor.
Currently ASImageNode would initially load the correct asset from the asset catalog but would not respond to changes in trait collections that would require loading a different asset from the asset catalog. This change allows use to use `-[UIImage imageAsset]` to reference the asset catalog entry for the current image and load the appropriate version based on the current trait collection
- Adding experiment to propagate older trait collections when trait
collections change
- Re-render nodes when user interface style changes (dark mode)
- Snapshot testing examples for dark mode
- Fixes for applying trait collection overrides in XCTest
- Create new define for gating Xcode 11 / iOS 13 features until CI is running it
* Allow full color tinting on grayscale template images.
* Signing a commit with the correct email address.
* Add snapshot test for a grayscale image with ASExperimentalDrawingGlobal enabled.
* Add support for tinting layer-backed ASImageNode's
* Move tint color support ASDisplayNode
* Address comments, unlock before calling "tintColorDidChange" on
subclasses
* Address comments
We rely on the delegate setter to be called to set the flag. However, recent change on iOS 13 causes the setter to not be called at all and thus we had to put up a workaround (https://github.com/TextureGroup/Texture/pull/1609). While the workaround works, the perf benefit of that the flag provides doesn't warranty the extra complexity IMO. So I think we should just remove everything.
- Add the ability to specify a tintColor for images / buttons that behave similarly to how they would under UIKit.
- Add flag to control if tint color is applied to ASTextNode to match how
UIKit controls if it is .applied to UILabel.
- Update tests for not-tinting automatic render mode for UIImage.
- Add property on ASTextNode2.
- Add tint color support to ASTextNode2.
It appears that UIKit might be setting the delegate ivar directly which bypasses establishing the `_delegateFlags` ivar on `ASDisplayLayer`. This is critical for things like ASPagerNode, ASCollectionNode that depend on layer delegateFlags to forward bounds changes.
Radar filed: FB6956185
We previously tried to optimize showing animated images (e.g. GIF) by calling
display link for updating the frame just when when we need the next frame, but
this resulted in some frames dropping when `frameInterval` wasn't respected like
you can find from this GIF:
https://i.pinimg.com/originals/58/9c/e8/589ce828d2ef0797da0e85b1c6d2f2b3.gif
Since the the display link fire method continues if we detect we're
at the same image index as before, let's just remove this optimization.
If the alwaysHandleTapTruncationAction is YES, the ASTextNode and ASTextNode2 can handle touches on additional attributed message even passthrough is YES.
Given that UIColor is now a dynamic provider we can no longer rely on the fact that there is a 1:1 mapping between UIColor <-> CGColorRef.
I've updated the UIViewBridge and ASPendingState accordingly to use UIColor and translate to CGColorRef only when interacting with layers. This should preserve any dynamic capabilities we might need in the future when trying to re-render layer backed nodes.
* Set background color directly to view or layer depending on if the node
is layerBacked.
Summary:
UIColor can now be a dynamic color provider to support capabilities like Dark Mode in applications. UIKit is able to re-render views when a user enters dark mode but this dynamic capabilities is not handled at the layer level.
Currently this takes the recommendation in facebookarchive/AsyncDisplayKit#1537 (comment) to set background color on the view directly or layer depending on if the node is layer backed. This change allows UIKit to track these colors and update the UI when the UITraitCollection.userInterfaceStyle changes.
* Updates to UIViewBridge to fix tests
* Remove opaque
* Test fixes
* Revert change to test checker method
* Fix strange issue where setting UIView backgroundColor sets the layer to
opaque to false
* Address Huy comments
* Address last comment
In iOS13, there is an issue with the font returned from "-[UIFontj fontWithName:size:]". When asking for "SFUI-Regular" returns "Times New Roman" font.
It isn't clear why we were trying to create a new font instance when CTFontRef toll-free bridges to UIFont. This appears to pass tests both internally at Pinterest and Texture so I feel like the change is pretty safe and should also solve the iOS 13 regression users are experiencing.
* [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.
Vlad Solomenchuk
Rahul Malik
Hanton Yang
Harry Shamansky
Mike Donahue
Greg Bolsinga
Michael Zuccarino
Jessie Alvarez
Huy Nguyen
Michael Schneider
Ray Sang Hyuk Cho
dirtmelon
Wu Zhong
ernestmama
Sterlingster
LiuJian
