* Test that the initial range bounds are what we expect
* Use the user's previous scroll direction in the range controller
* Remove flow layout assertion
* full screen button for ASVideoPlayerNode
* fixed a small issue when disabling controlsDisabled is set
* styling fixed
* make videoNode public on ASVidePlayerNode
* [ASVideoPlayerNode] fixed an issue when re-enabling the controls the duration time label didn't updated correctly
* [ASVideoPlayerNode] Check if CMTime is valid before setting the labels
* Improve visibility handling for range-managed nodes
* Tweak ASWeakSet & the test
* Put back a few things that are pending a different diff
* Add a test
* Ensure we update visible nodes, even if there are no new ones
* Implement mutex ownership and use it to check potential upward lock gathering
* Don't hold instance lock and call willEnterHierarchy/didExitHierarchy of ASDisplayNode
- This can cause deadlocks (e.g #2605) if subsequent methods, that are implemented by developers, walk up the node tree.
- This is a way to keep the optimizations introduced in 9e87813 while making sure the locking situation is a bit safer.
* More lock ownership assertions in ASDisplayNode
* Document main thread contract of -clearContents
* ASNetworkImageNode shoud not call setNeedsPreload while holding instance lock
- This helps to avoid potentially deadlocks caused if the node (esp in case it's a subclass of ASNetworkImageNode) walks up the tree in didEnterPreloadState, for example to build logging context.
* ASVideoNode should not call setNeedsPreload while holding instance lock
- This helps to avoid potentially deadlocks caused if the node (esp. if it's a subclass of ASVideoNode) walks up the tree in didEnterPreloadState, for example to build logging context.
* Don't hold instance lock for the entire insert subnode operation
- The recursive lock should not be held throughout `_insertSubnode:atSubnodeIndex:sublayerIndex:andRemoveSubnode:`. The method instead should manage the lock itself and acquire it as shortly as possible. The reason is that this method calls many methods outside the scope of `self`. `[subnode __setSupernode:self]` is especially troublesome because it causes the subnode to migrate to new hierarchy and interface states, which triggers `didEnter/Exit(.*)State` methods. These methods are meant to be overriden by subclasses. Thus they might walk up the node tree and potentially cause deadlocks, or they perform expensive tasks and cause the lock to be held for too long.
- Other methods that call this method should release the lock before doing so.
* Lock getter and setter of `synchronous` flag
* Address comment in ASVideoNode
* Add main thread assertions to methods that change asset and assetURL of ASVideoNode
* Explain CHECK_LOCKING_SAFETY flag
* More thread and locking assertions in ASVideNode
- It's not safe to call `-[subnode __setSupernode:self]` while holding instance lock of soon-to-be supernode (e.g `self`).
- It's also not safe to call `[subnode __setSupernode:nil]` while holding the instance lock of the old supernode (e.g `self`).
- did(Enter|Exit)(.*)State methods are always called on main. Add main thread assertions to indicate that.
* Minor change in explanation of CHECK_LOCKING_SAFETY flag
After much discussion I think this is the correct behavior. It seems
like it's much more likely to be the expected behavior but still enables
you to use the network image node like an regular image node.
* Add nullability declarations in ASDisplayNodeInternal.h
Fixes#2701
* Use NS_ASSUME_NONNULL macros in ASDisplayNodeInternal.h
It reduce visual clutter and keep file in line with most other header
files.
* [ASDisplayNode] Remove node from supernode before adding it as a subview
If a node is being added as a subview to a UIVIew, we must make sure to remove it as a subnode of its supernode.
* remove from supernode if adding to a layer.
