Design what happens to completion events when playback jumps backward #60
Labels
design
A design remark or improvement
Comments
djeedai
added a commit
that referenced
this issue
Oct 2, 2022
Add two new methods to the `Tweenable<T>` trait: - `set_elapsed(Duration)` sets the elapsed time of the tweenable. This is equivalent to `set_progress(duration().mul_f32(progress))`, with the added benefit of avoiding floating-point conversions and potential rounding errors resulting from it. `set_progress()` is now largely implemented in terms of and as a convenience wrapper to calling `set_elapsed()`. - `elapsed()` which queries the elapsed time of the tweenable. This is equivalent to `duration().mul_f32(progress())`, again with better precision. The elapsed API is the recommended way going forward to manipulate a tweenable's time outside of the normal `tick()` flow. It supersedes the progress API. This change purposedly skips any discussion about what happens to completion events when `set_progress()` or now `set_elpased()` is called with a lower value than the current one to seek time back. This design issue is logged as #60 and is still pending. The change also partially addresses #31, but without removing any existing API or feature.
Merged
djeedai
added a commit
that referenced
this issue
Oct 2, 2022
Add two new methods to the `Tweenable<T>` trait: - `set_elapsed(Duration)` sets the elapsed time of the tweenable. This is equivalent to `set_progress(duration().mul_f32(progress))`, with the added benefit of avoiding floating-point conversions and potential rounding errors resulting from it. `set_progress()` is now largely implemented in terms of and as a convenience wrapper to calling `set_elapsed()`. - `elapsed()` which queries the elapsed time of the tweenable. This is equivalent to `duration().mul_f32(progress())`, again with better precision. The elapsed API is the recommended way going forward to manipulate a tweenable's time outside of the normal `tick()` flow. It supersedes the progress API. This change purposedly skips any discussion about what happens to completion events when `set_progress()` or now `set_elpased()` is called with a lower value than the current one to seek time back. This design issue is logged as #60 and is still pending. The change also partially addresses #31, but without removing any existing API or feature.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The
set_progress()(and discussedset_elapsed()) method allow you to move the animation to an earlier point than the one it's in currently. Traditionally for tick-based animation the tween will emit a completion event each time it's completed. However, when playback jumps backward, it's unclear what should be done for completion events, especially when the tween is repeating, and jumping backward can decrease the completed count (times_completed) by more than one.Conceptually it feels like jumping backward this way is not a natural way of animating, and is more geared toward editors or manual seeking, so it feels like ignoring completion events (and callbacks) in that case is the best approach.
Note however that there is also the playback direction which allows smooth playback but in reverse order. Although this is a distinct and probably orthogonal feature (it only swaps the endpoints of the lens), conceptually it can be confusing to make a distinction between "moving by 1 second in backward direction" and "seeking 1 second before the current point", which both result in the same state for the underlying animated component, but not for the tween which has a different direction.
The text was updated successfully, but these errors were encountered: