Allow specifying duration of movement time #320
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR implements something that we want in CosmicDS, which is the ability to specify the duration of a movement between two locations.
As for how I implemented this:
duration
parameter to our parameters that control goto movements. This represents the desired duration of the move, in seconds.ViewMoverKenBurnsStyle
andViewMoverSlew
. The Ken Burns-style mover already has a parameter for the time to target, so almost all of the work here is for the slew mover. We generally create the slew mover via itscreate
function (in fact, I think that's the only way that we do in the codebase), so I've updated that function to take in aduration
parameter. If the caller doesn't pass anything in, this will be undefined, and the behavior is left unchanged from what it is currentlycreateUpDown
, and set appropriate values for the various factors to give the desired duration. However, this isn't possible due to the second term in this line, which doesn't have a prefactor that we can adjust. Thus, the approach taken here is a simpler one: create the view mover and let it figure out its times, then adjust the up/down/total times to have the same relative sizes, just scaled to fit the desired duration. This works because only the target time variables are used for the interpolation - the up/down/travel factors are only used ininit
. If not for how they're used increateUpDown
(whose API I assume we don't want to change), they could just be scoped to that function.If anyone wants to test this out, I've set up a demo here that allows specifying the various parameters. Similar to the time functionality exposed in #222, the actual time for the movement will within a few milliseconds of the requested duration.