Open toulouse opened 10 years ago
Using just public headers, you should be able to do this with a N+1 animations, where the N+1th animation was a custom animation that did the coalesced view writing. POPAnimatorObserving is however more robust since it'll by definition be applied after all other animations, making the solution robust against changes in animation ordering.
I see. A "flush barrier" is one way I thought of, but I'm not sure the animation ordering is explicitly guaranteed, so I didn't consider the possibility further.
Thank you for reporting this issue and appreciate your patience. We've notified the core team for an update on this issue. We're looking for a response within the next 30 days or the issue may be closed.
https://www.facebook.com/groups/551597518288687/permalink/592691350845970/
In my particular case, I have two spring animations operating on independent inputs to a layout spec* object. Currently, I'm updating my views by overriding the write block to trigger flushing the newly-calculated outputs into my views, but with two animations, this means I'm doing N re-computations and view update passes per frame, where N is the number of animations operating on the layout spec.
This is clearly suboptimal; I only want to flush the updates once per frame. Using the animator to observe the update seems to be the best solution for now, but requires copying the header file
POPAnimatorPrivate.h
, which is currently private.A mechanism to register interest in specific animations and get a coalesced notification (at most one per display link tick) when those animations (or a subset) are updated would be ideal.
* a plain old NSObject with input properties plus a -layout method that outputs calculated values into read-only properties