DisplayObject.animating property not accounting for all animations?

Questions
1

When I do something like this...

disp.animate({id: "1", props: {prop1: ...});
disp.animate({id: "2", props: {prop2: ...});

disp.stopAnimate("1"); // same result with "2"

...then disp.animating gives false even though prop2 is still animating. Is the animating property behaving as expected? If so, is there an overall/any animating state that can be read?

2

Yes... not the best arrangement but handy for a single animation. The animating property is a convenience property for paused - it is the opposite of paused and paused is true as soon as any animations are paused. There is a tweenState property that has the states of all of the tweens. This situation is described in Docs for the paused property - we will refer to it more specifically in the Docs for animating property and give it some thought for 018.

It may be that we should make a getter setter poll the tweenStates and if any are animating, set animating to true. I suppose, the same for paused as it could be considered not paused if any are animating. Just tricky to pause an animation then report that it is not paused.

1 Like
3

Similar to how stopAnimate and pauseAnimate take an optional id, it would seem that .animating and .paused would also be roll-ups, and individual checks would be something like .isAnimating(id) and .isPaused(id). Of course changing .animating would be a breaking change, so new methods would be less impactful (but more weight), if it's even worth doing.

For now I'm keeping a counter that decrements on props.call. Due to not having a callback on .stopAnimate (my other post), I'm also managing their counters manually upon timeouts. The idea was to use .animating instead of counters and timeouts.

My use case is that I have a "declarative" JSON layout that is consumed by a processor, and the JSON can have decision points where sequenced and potentially overlapping animations are waited on.

1 Like