Skip to content
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

Open
david-stefan opened this issue May 14, 2015 · 6 comments
Open

Decay issue #88

david-stefan opened this issue May 14, 2015 · 6 comments

Comments

@david-stefan
Copy link

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.

@phirschybar
Copy link

I am trying to find a workaround for this too.

@phirschybar
Copy link

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: setInterval(function(){ $('body').trigger('mouseenter'); }, 1000);. Every second we trigger the mouseenter event. This keeps the decay alive. Hope this helps somebody else until a more elegant solution can be found.

@patricknelson
Copy link

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 pointerOffTarget and pointerOnTarget respectively.

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 pointerFn which is defined on initialization of parallax itself being totally different). So the only way to properly hand this off between being "on target" and "off target" is to, in the pointerOnTarget function, make a call that updates the original scopes pointerFn to reference pointerOffTarget via yet another parameter being added to both of these functions, or, setup an event similar to mouseenter.parallax which exists in the correct scope. e.g.

'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:

  1. The responsibilities here in the initial jQuery call should be to select the view port first and then pass an option to it with a selection of the layers inside of it, not the other way around (i.e. currently you call the .parallax method on a jQuery selection of ALL the layers and then when each layer initializes, it then has to re-reference it's viewport). This also leads to other weird complexities such as the really weird/funky technique of defining options for each layer (e.g. the parallax offset). To make it'd make more sense to define that as a data attribute on each layer or call the parallax plugin (after defined on the viewport), pass a selector for the layer whose attributes/options you want to change and then the name/value pair of the attributes.
  2. The maintenance of state should use objects with properties and methods on those objects instead of defining functions inside of a particular scope and then having to add parameters and pass these functions as parameters to other functions and etc. May as well just go OOP instead of passing pointers/references around.

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.

@patricknelson
Copy link

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 pointerOnTarget is called, the timer is still running which is still eating some CPU and (apparently) GPU.

GPU graph (from process explorer)
screenshot 2

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.

patricknelson added a commit to patricknelson/jparallax that referenced this issue May 12, 2016
… 'pointerOffTarget' when mouse moves back away from target.
patricknelson added a commit to patricknelson/jparallax that referenced this issue May 12, 2016
… 'pointerOffTarget' when mouse moves back away from target.
@patricknelson
Copy link

See PR #92 which provides a fix for anyone out there seeing this issue.

patricknelson added a commit to patricknelson/jparallax that referenced this issue May 12, 2016
… 'pointerOffTarget' when mouse moves back away from target.
patricknelson added a commit to patricknelson/jparallax that referenced this issue May 12, 2016
… 'pointerOffTarget' when mouse moves back away from target.
patricknelson added a commit to patricknelson/jparallax that referenced this issue May 12, 2016
…followPointer'.by removing need for separate on/off frame animation functions.
patricknelson added a commit to patricknelson/jparallax that referenced this issue May 12, 2016
…followPointer'.by removing need for separate on/off frame animation functions.
@patricknelson
Copy link

patricknelson commented May 12, 2016

I've actually simplified this further and refactored to followPointer by removing the need for a separate set of on/off frame animation functions. Now it's just one main function which then terminates after a delay (on mouseleave).

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 pointerFn but instead concrete followPointer function). So the full list is:

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants