Efficiently coordinating multiple animators on a composite object

[jverkoey]

I am animating an MKMapCamera and have different animators for each of the sub-properties which I use to animate different properties of the camera with different vibes.

AnimationGroup seems like it would be a natural candidate for this, but the interface assumes you're using the same Animations for the lifetime of the group, and that they all run as a unit. I want to be able to initiate and even hand off animations from one type to another (e.g. a decay that turns into a spring), so the AnimationGroup is a bit too restrictive as-is.

One thing I'm playing with but is somewhat messy in its own way is to introduce events at the start and end of Animator's tick pump, like so:

    // MARK: - AnimationDriverObserver

    public var tickWillStart: (() -> Void)?

    /// Informs an observer that a tick occurred and that one or animations updated.
    public var tickDidEnd: ((Bool) -> Void)?

    func tick(frame: AnimationFrame) {
        tickWillStart?()

        var anyAnimationUpdated = false

        for animation in (runningAnimations.copy() as! NSHashTable<AnyObject>).objectEnumerator() {
            // This is such a hack.
            if let animation = animation as? AnimationDriverObserver {
                animation.tick(frame: frame)
                anyAnimationUpdated = true
            }
        }

        tickDidEnd?(anyAnimationUpdated)
    }

This allows me to set up scratch state at the start of the tick, mutate it with any animators that are running, and then commit the result atomically, rather than having each animator commit the presentation data to the model layer individually.

Curious on any thoughts on this!

[b3ll]

Apologies for the late reply! I’m catching up on all my projects after the holiday break 😅

So I can promise that AnimatorGroup was made “just because” and that’s barely all the thought I gave to it. I don’t think I’ve even really used it for anything… so I’m happy to repurpose / potentially revisit some of how it works.

That being said, having a set of animations and coordinating those separately should be pretty efficient since all the calls are batched each frame tick (it’s also basically zero cost to toggle them on/off). Is it just cumbersome to work with on your end?

[b3ll]

friendly ping @jverkoey :)

[jverkoey]

Also apologies for the delay 😅

Is it just cumbersome to work with on your end?

Exactly. From my performance measurements, it turns out that modifying the MKMapCamera immediately results in CPU-intensive work happening, and when you have multiple animators each committing changes to the MKMapCamera instance this ends up being quite expensive.

The solution I ended up with looks something like this:

animationEnvironment.animator.tickWillStart = { [weak self] in
  guard let self else {
    return
  }
  scratchCamera = cameraModel?.copy() as? MKMapCamera
}
animationEnvironment.animator.tickDidEnd = { [weak self] anyAnimationsChanged in
  guard let self else {
    return
  }
  if anyAnimationsChanged,
     let scratchCamera {
    updateCameraModel(scratchCamera)
  }
  scratchCamera = nil
}

The result of this is that I can have a bunch of animators all operating on parts of the camera with only a single commit operation, which ends up being much more efficient.

[b3ll]

Gotcha, that makes sense. I was thinking moreso in terms of CATransactions / the animation ticks themselves being expensive, but I'm glad that's not the case.

I'm still thinking of an alternative to adding global tick delegates, maybe some sort of animation aggregator (that doesn't care about the types?), but then you end up reimplementing the global animator anyways lol

Do you have an example PR to add this? I'm curious how messy it gets