I'm liking the way Hammerspoon does animations. In short, it drives the animation from its own event loop, dispatching writes at a set interval (looks like it's 10ms or so). I wasn't sure if such an approach would work, but it looks pretty decent to me on my machine.
Some thoughts on implementation...
Animations should happen on a per-property basis.
While a property is being animated, we can keep the property's requestLock locked so no other reads/writes go through
This means no events on the property until the animation is done. external would be properly set.
Synchronous writes under a timer are probably the best approach. That way we don't pay the overhead of scheduling a function on the event loop.
On the other hand, if we are animating many properties at once, do we want many timers firing? Would only one be best? Many timers would provide "fairness" so that one application can't freeze out the rest, but it might be inefficient.
Perhaps one per application?? Pass an AnimationContext to each writeable property which contains the timer, and have one per application.
Also, don't forget that we can use timeout.
The core Animation class should simply provide the proper integration with the property internals. Allow a user to compute the actual values for each animation step. Include a simple "linear schedule" to get started. API should be similar to Cocoa animation APIs.
Is there a way to actually use the Cocoa animation schedules with our class?
I'm liking the way Hammerspoon does animations. In short, it drives the animation from its own event loop, dispatching writes at a set interval (looks like it's 10ms or so). I wasn't sure if such an approach would work, but it looks pretty decent to me on my machine.
Some thoughts on implementation...
requestLocklocked so no other reads/writes go throughexternalwould be properly set.AnimationContextto each writeable property which contains the timer, and have one per application.timeout.