Effect of delay property unexpected
Closed this issue · 6 comments
Adding a delay pads the animation with the initial state for the duration of the delay, making queuing a bit trickier—as the start callback is executed immediately, and the step callback is executed even during the delay period.
Suggest changing delay to defer execution of the tween instead.
Hi @acies, thanks for opening this issue! The reason that delays "pad" the animation as you described are so that they can be preserved in the case where the tween is paused and played again. So, this is intentional behavior, but I was sort of guessing at what would be the most intuitive way it might work.
I'm hesitant to change this behavior because that might affect downstream projects that already use it. Could you explain how this creates problems with queuing tweens?
The delay functionality was born out of #65. I wonder what @Kris-B thinks about this change?
Hi @jeremyckahn and @acies
I not sure to understand all possible impacts...
Would it still be possible to cancel an animation during delay (I'm using tweenable.stop(false)for this) ?
@Kris-B Well, we should certainly aim to retain that functionality if we decide to make this change, and I think it should be possible to do so.
Thank you for the response.
You can observe a conflict as a result of this if you initialize multiple tweens simultaneously—the other with a delay—both manipulating the same property. Or if you want to manipulate the same values while waiting, say with a hover.
https://jsfiddle.net/acies/sunv57bb/
My personal opinion is that start should indicate when the actual tweening begins, and the step callback successively called after this.
If you still initialize the render loop immediately, you could leverage this to diff the initial time, with delay added, with the current time, to determine when it should start, and still be able to pause/play.
After checking my source code, I noticed that changing the current behaviour could have some effects: some code is running in each step callback, even during delay....
@acies Thank you for putting together that demo! I can see what you mean more clearly now.
Given that this change would affect users like @Kris-B, and that I have a slight preference for the current behavior, I would prefer to keep this as-is. However, there should be a way to achieve the behavior you want without any changes to Shifty. Specifically, start the second tween inside of the finish handler for the first tween. Would something like that do the trick?
I am going to close this issue for now, but I am happy to continue discussing this here.