Very often I have to do hand animation,
SomeView: UIView
startAnime
startAnotherAnime
yetAnotherOne
interruptSecondOne
reverseThirdOneButDontInterruptFirstAnime
etc etc
and so on.
Obviously you just get a CADisplayLink callback and draw (or whatever) using that:
startAnime
dl = CADisplayLink(target: self, selector: #selector(update)) etc
@objc func update()
let value = _calculate(forTime: current time)
if animation finished dl = nil etc etc
draw(blah blah )
height = value
Of course, you carefully eliminate the CADisplayLink when an animation/s is/are finished, launch one to begin another animation, etc etc
But it occurred to me.
Why not simply create a CADisplayLink callback when the view is iniitialized .. and forget about it?
Just have it called every frame (like in any graphics engine).
public required init?(coder aDecoder: NSCoder) {
super.init(coder: aDecoder)
common()
CADisplayLink(target: self, selector: #selector(update))
}
@objc func update() {
// ordinary "Update" -like call as in any ordinary graphics engine.
// it's "always here". Use as you see fit
if .. no animations going on { return }
}
To put it briefly,
Has anyone looked in to this, if it eats much performance, or causes any other problems?
(You wouldn't think it would cause any performance problems, but, iOS really really wants to be a tween, it doesn't want to be a frame loop, so maybe they do something in a weird way - who knows?)
(Pls note, the one instruction to go "return" when nothing happening, is a non-issue.)
Why bother creating CADisplayLinks when needed, why not just have one all the time, if a class will be using one a lot?
After all, when you add other targets to a class (say, a gesture), you just "add it and forget" an initialization time; you don't generally add it / take it away on demand. (Of course a loop link is different since it goes every frame, but still.)
Is there a downside I'm not knowing about?
