Jump to content
Search Community

onPause and onResume events

Dave Stewart 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

Would also be cool to have onLabel events, which could be really useful to trigger external functions as the playhead hits timeline markers..


I guess the workaround for the time being is to add a callback at the same time:

function addMarker(tl, label, time, callback, params, scope)
​    tl.addLabel(label, time).call(callback, params, scope, time);
Link to comment
Share on other sites

Hi Dave,


The main reason is that ultimately is not needed. In every case we've seen around in the forums, pause, resume and reverse methods are always triggered by a specific event handler (click, mouse-in, mouse-out, etc., or even in a GSAP specific callback) so whatever code the developer needs to execute at that particular moment can be referenced in the same event handler.


AS for the onLabel event, you can use the call() method in order to add a specific callback at a specific label on the timeline:

var tl = new TimelineLite();

tl.call(myFunction, "label1");



If the label doesn't exist GSAP will create it at that position and it can be referenced later in your code.



Link to comment
Share on other sites

Well, decoupling is a perfectly reasonable requirement.


Take my 

See the Pen wlFDf by davestewart (@davestewart) on CodePen

example. The whole point of that test was to work out how to show a global overlay when the timeline pauses.


Using an interim addPause() method seems like the best bet to decouple behaviour from animation, and should be agnostic as to what timeline its pausing. It should just tell a timeline to pause, and it should pause. 


At the same time, the method should not be tasked with any additional functionality, as I may not want to (or it may not be convenient to) introduce code at this point to control other elements within the page, say for example:

  • a "playing" indicator 
  • a "your game is paused" overlay
  • an options menu

Each one would have its own encapsulated logic, for view elements, interaction, etc.


So let's say we have all 3 of these, and each needs to respond to the state the timeline is in.


By having to add code to inform each of these elements within the addPause() function, we make the timeline code tightly-coupled and fragile.


An alternative might be to create a PlayStateEventManager instance, which the addPause() method could inform when the timeline pauses, and that could in turn have event listeners added or removed from it, but then we're adding a new object and additional wiring, that doesn't need to be there.


Simply being able to add listeners to a timeline to respond to change in play state not initiated by a user action would solve this.

Make sense?

Link to comment
Share on other sites

Hey Dave,


It makes total sense what you're pointing. Let me say as well, that this issue has come up a few other times before (not too many though) so I'll point you to a couple of replies by Carl and Jack that could explain better the trade-off of this features:




And reply #12 by Jack in the same post.


Finally this reply by Jack some time ago:





Link to comment
Share on other sites

We've been asked a few times for this functionality (very, very rarely) and I think this just fell into the category of things that we couldn't quite justify the additional kb that'd be necessary to support it, especially since it's really not very hard to write your own external code to do the same thing. 


Another way of saying it is "should we make 100% of the users pay the price for a feature that less than 1% would actually use, even though it'd be pretty easy to leverage external code to accomplish the same thing?"


This isn't a bad idea at all, by the way - don't hear me saying it's a silly feature request. It's just that we've seen other tools that keep adding feature after feature after feature and pretty soon "TweenLite" would become "TweenFat" if we followed that same path, so we try to only add things that can't be done outside the core engine effectively, or things that are so convenient and so commonly requested that the extra kb (and performance cost) is justified by the sheer quantity of people it'd serve or the way it'd smooth out workflow. 


I'll keep this in mind for future versions if enough people request it. 


In the mean time, like you said, it should be pretty easy to code around. Like have your own centralized pause() and play() functions that control the timeline(s) and dispatch whatever event(s)/callback(s) you need. 


Thanks again for the thoughtful suggestions and questions, Dave. You're clearly someone who is putting the toolset to good use and leveraging advanced features which is great. I love to see developers who understands how powerful timelines can be in terms of animation workflow. Nice to see someone who "gets it" :)

  • Like 3
Link to comment
Share on other sites

Hey guys,


Thanks for putting together some well-thought out responses. And Rodrigo, for digging through the forum posts to get me up to speed on prior conversations.


Totally agree (again) about the balance between speed and power, especially when probably the majority of users are just creating fairly simple timelines. Though it feels like these events would complete the play-state "family" of events.


However, in light of your very reasoned responses, it would be silly for me to say much more to support my case, or else I'll turn into one of those "but my need is different" types!


The only thing I'd say from my cursory look at the source, is that any impact on KB looks like it would be negligible (being that the event calling would be confined to a couple of places only) and performance would be a non-issue seeing as at one point of either event, the timeline would be stopped anyway!


Anyway, after building about 10 Pens and testing a whole bunch of stuff out, from nested timelines, to events, pauses, callbacks, etc., etc., I'm about to build my 11-scene monster animation now, with pauses and all that jazz, so no-doubt I'll have a different perspective once done.

I'm all tooled up with the various workarounds needed, so perhaps I'll comment back when done.


Thanks again for the input, and the kind words, Jack.



Link to comment
Share on other sites

I'm not super concerned about performance in this case, but here are some of the costs, FYI:

  1. Add onPause, onPauseParams, onPauseScope, onResume, onResumeParams, and onResumeScope "special properties" which entails putting them in the reserved props hash lookup. Obviously this adds some kb, but also since we've got 6 more reserved properties, it impacts lookup performance slightly for every...single...tween. 
  2. Adding 2 new lookups for "{self}" parameters
  3. Adding the necessary code to trigger the callbacks anywhere that the _paused property is affected.
  4. Adding 6 special properties to the docs for each of the following classes: Animation, TweenLite, TweenMax, TimelineLite, and TimelineMax.

Anyway, good luck with your 11-scene monster. I'd love to hear your feedback after you go through that trial by fire and see how well the tools serve you, where any rough spots are, and what your favorite features are. 



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...