-
Notifications
You must be signed in to change notification settings - Fork 333
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Decay issue #88
Comments
I am trying to find a workaround for this too. |
I had a very hard time getting this to work. But since parallax is just a cosmetic feature of a site I am working on I concluded with a NASTY hack to get this to work. Basically it is this: |
I've determined the root cause of this issue. This issue emerges from a general root/underlying issue associated with variable scoping and context. For example -- once the parallax finally reaches it target (after the end of the decay) it switches the "current" animation function (i.e. the function responsible for animating the current viewport) from an "off target" animating function to an "on target" animating function (or really just a function that idles), with the functions being The issue is that the state used to maintain which function is the "current" function is maintained in a totally different scope. That then means the "off target" animating function doesn't currently have the ability to hand animating back to the "off target" animator (due to the scope of the original 'parallax.setPointerFn': function setPointerFn(e, newPointerFn) {
pointerFn = newPointerFn;
} ... and then call that event. I can setup a PR to address that, but that doesn't really address the underlying issues. In my opinion, there should be two major things done here:
I will submit a PR with my event-based hack/fix since I don't have time to rebuild/refactor this for a good PoC for items 1 and 2 outlined above. |
Also, by the way, I think making this more object-centric offers the opportunity to make the idling a bit more efficient, since I notice that once the target is reached and GPU graph (from process explorer) Here you'll see the first spike which is the actual animation while the mouse is moving. In the middle of that first plateau the mouse stops moving and the animation decays to a resting point. The resting point is that middle plateau. Finally, I move the mouse out of the view port, which causes that last spike/plateau, at which point the timer stops completely, no longer eating up the GPU/CPU. |
… 'pointerOffTarget' when mouse moves back away from target.
… 'pointerOffTarget' when mouse moves back away from target.
See PR #92 which provides a fix for anyone out there seeing this issue. |
… 'pointerOffTarget' when mouse moves back away from target.
… 'pointerOffTarget' when mouse moves back away from target.
…followPointer'.by removing need for separate on/off frame animation functions.
…followPointer'.by removing need for separate on/off frame animation functions.
I've actually simplified this further and refactored to What do you think @stephband? Also I setup touch compatibility in PR #91 and a fix for the initialization problems noted in issue #87 in my PR #89. I mention my other PR's since they would be affected by the PR #92 fixing this issue (i.e. no longer calling abstract reference
|
Decay resets to 0 when mouse stays inside of the mouseport.
After leaving the mouseport, decay switches back to desired value on entering the mouseport again.
The text was updated successfully, but these errors were encountered: