Jump to content
Search Community

setting tween priority in relation to ticker callbacks?

erikb test
Moderator Tag

Warning: Please note

This thread was started before GSAP 3 was released. Some information, especially the syntax, may be out of date for GSAP 3. Please see the GSAP 3 migration guide and release notes for more information about how to update the code to GSAP 3's syntax. 

Recommended Posts

I am listening for events on the ticker at different priorities.

 

Tween events fire at priority 0, so I arrange my other ticker callbacks around that.

 

One of the events I listen for at priority 100 (before tweens).  This event checks if a scrollable area has had an update to its scrollTop which could happen from a scrollwheel between ticks.  Based on the new scrollTop value, I do some book keeping on what elements are now in view.

 

Then, when we get to priority zero and the tweens update, proxy objects ensure only those elements in view get updated with nifty css effects.

 

Last night, I tried using the scrollTo plugin and got odd behavior from my current setup.  Since the scrollTo update is presumably firing on priority zero, it is happening after I am normally doing my book keeping for changes to scrollTop on priority 100.  Therefore the wrong elements are getting updated when there are large scrolls movements.

 

I plan to work around this by keeping track of the time passed and on priority 101 using a variant on the technique described here:

http://greensock.com/forums/topic/12534-pick-value-between-2-css-values-using-gsap/ to update the scrollTop value.  This is feels funky.

 

It would be super if I could set the priority of a tween to fire at a different priority (in this case, I would fire the scrollTo plugin at priority 101).  

 

Link to comment
Share on other sites

Alternatively, if I were to move all of my book keeping to priority zero, how would I know scrollTo had changed the scrollTop before I applied my other tween to update only the elements in view?  Is there a priority for tweens?  Thanks for helping me to figure this out.

Link to comment
Share on other sites

It's actually impossible to have priorities on tweens because the very nature of an animation system requires that things render in a very particular order based on timing. For example, if you've got a tween to x:100 in a timeline and another tween after that one that animates to x:500, imagine what would happen if the 2nd one (in order) rendered BEFORE the first (because you assigned it a higher priority)? x would end up at the wrong place. And everything needs to be inverted when the playhead is going the other direction. So offering priorities on tween rendering would kinda break the whole system :) 

 

Like Blake said, though, you can manually trigger a tween/timeline to render at whatever progress you want whenever you want, so you could just hang onto a reference of your scrollTo tween(s) and render it inside your priority:100 handler if you want. 

  • Like 2
Link to comment
Share on other sites

Thanks guys, this is helpful.

 

Here is an example of the situation I have (should have done this first... sorry):

See the Pen KrJvgr by jedierikb (@jedierikb) on CodePen

 

When I scroll by hand up and down the proxied color animation is always in bounds.

But when the tween takes over the scrolling (by pressing the link), the proxied animation is a step behind.

 

How are you suggesting I force the animation which updates the scroll to update before the ticker callback on priority 100?  Much thanks!

Link to comment
Share on other sites

I think you might be overcomplicating things a bit. Whenever I run into a situation like this where, for example, I find my code leaning on a very particular order of firing things that's really difficult to manage, it's a clue to me that I might have some faulty engineering or there's a simpler solution somewhere. In your example, I'm not entirely sure why you're doing all those operations on every single tick (seems a bit wasteful to me), but if your goal is to make sure that the "lastBlocks" array gets populated according to the new scrollTop AND that the colors get applied to those lastBlocks, you could just add this to your scrollTop tween:

onUpdate:function() {
      scrollListenerCb();
      updateCb();
} 

Oh, and a few other minor notes:

  1. There's no such thing as an "onReverse" callback
  2. I'd be careful about animating "scrollTop" directly since that doesn't always work in all browsers for all objects (like the window), plus it won't auto-kill itself when the user interacts with the scroll position. I'd recommend using the ScrollToPlugin instead for all those conveniences. 
  3. I assume you were just whipping that codepen together super quick and this is irrelevant, but some of the code seemed pretty inefficient. For example, you had a loop like "for (var k = idx; k < Math.min(idx + 11, 500); k++) {..." which would be quite slow due to the fact that you're calling Math.min() and performing math on every iteration. It'd be better to save that value as a local variable and plug it in there. Again, you probably already know this stuff and just wanted to keep the code brief for the codepen without worrying about performance. Figured I'd mention it though. 

Does any of this help? 

  • Like 1
Link to comment
Share on other sites

Thanks Jack.  The code was written with small nephews and nieces crawling over me on a small laptop.

I am surprised I was able to demonstrate my issue at all.  :-P

 

Regarding #2, I forgot codepen comes loaded with all of the good plugins.

 

Your suggestion is a good one:

See the Pen ZOwaNp by jedierikb (@jedierikb) on CodePen

 

However, this only updating the lastBlocks when tweening the scroll position -- it does not update when scrolling by hand.

 

I was, however, able to implement a satisfactory solution to my issue:

See the Pen oLVvJj by jedierikb (@jedierikb) on CodePen

 

On 101 I check if  a paused tween to move the scrollTop was created.  Iff that paused tween has been created and we've not passed its duration, I then set the elapsed time on that paused tween which (thankfully!) updates the tween immediately, changing the scrollTop position.

On 100 I check if the scrollTop has changed (either from a tween or user scrolling) and do my book keeping on what is in view.

On 0, the pulsating tween updates those elements now in view.

 

Slightly awkward, yes.  But it 'works for me' :-)

 

Much thanks!

  • Like 1
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...