Closed SBoudrias closed 4 years ago
I'd be fine with this. I just want to make sure not to change the API in a backwards-incompatible way. I think just adding a parameter to optionally disable the scheduling logic should be sufficient. How do you feel about that approach?
I'm not sure when I can get to this, but it should hopefully be within a few days. Feel free to make a Pull Request if you need this change before then.
@SBoudrias, can you review this patch? I think it should address the issue.
Hey @jeremyckahn I think that'll fix https://github.com/jeremyckahn/shifty/issues/62 correctly.
But for this specific issue, I think we could gain performance if seeking weren't triggering a timeoutHandler
call.
Oh dang, I was looking at the wrong issue tab in my browser, hah. I'll make a new branch and move this conversation over to #62.
Closing this due to inactivity. I'm happy to reopen this for a PR, in case anyone is interested in providing one.
I remember from past discussion that
Tweenable#seek()
wasn't a method designed into shifty when it got created.As so, when calling
#seek()
, we actually just set the play head to a specific value and triggers a timeout handler.I believe
#seek()
shouldn't think about scheduling and should simply update the state of the tweenable then call the step methods synchronously.It might make sense then to actually calls the seek method internally when playing a tween (the
timeoutHandler()
could actually calls#seek()
). Then seek might really be built into the core and fit better with other parts. Thoughts?