Jump to content
Search Community

Global onUpdate

SntsDev test
Moderator Tag

Go to solution Solved by GreenSock,

Recommended Posts

When adding a listener to the ticker, it fires from start to infinite. Even when it's NOT doing animations. The parameters of the function called say nothing about effective work.


I'm interested on having some kind of `onUpdate` global event. To know exactly when GSAP is working on ANY instance. I'm trying to save rendering frames in WebGL from the CPU. Among other things, this is needed. To add that to every animation would be a lot of work and depend on the developer. Is it possible to have a global event of effective animation work?

Link to comment
Share on other sites

Thanks @ZachSaucier. Exactly, I prefer to not depend on the developer of a particular task. I want to set up something that doesn’t depend on remembering to do it. Apart that, from the maintainability point of view, if needed, we would need to change things in many places or define a global function, and, if not needed anymore, make that function to do nothing and leave dead code here and there. 

Link to comment
Share on other sites

  • ZachSaucier changed the title to Global onUpdate
18 minutes ago, ZachSaucier said:

SntsDev please correct me if I'm wrong here, but I think they want it only to fire if an animation on GSAP's timeline is actively updating.

So you want an onUpdate on all your animations...but you don't want to add it to them all and you don't want to use it as a default? Yeah, aside from the solution I offered which would fire after the global timeline updates every tick (and it'd stop soon after the whole animation queue is done), I don't see any better options.

Link to comment
Share on other sites

2 hours ago, ZachSaucier said:

SntsDev please correct me if I'm wrong here, but I think they want it only to fire if an animation on GSAP's timeline is actively updating.

You're correct @ZachSaucier.

@GreenSock, your answer is not what I'm looking for. That listener just says that it's ticking. It's equivalent to adding a callback to the ticker.

Zach described it perfectly: to know when GSAP's timeline is actively updating ANY animation.

Link to comment
Share on other sites

4 hours ago, SntsDev said:

That listener just says that it's ticking. It's equivalent to adding a callback to the ticker.

That's incorrect. When you add a ticker listener, it will always fire on ever requestAnimationFrame (never sleep) whereas my solution will power down when GSAP is able to power down, like when there are no animations in the queue for a while. 

 

What you're asking for would be pretty inefficient to accommodate inside GSAP. You could just write your own helper function that you feed your animations through and it would automate the whole onUpdate additions so that you've got a central place to do it.   

  • Like 1
Link to comment
Share on other sites

Thanks @GreenSock for that clarification. I understand that there is a default of 120 seconds where GSAP continues to work before going to sleep if it can, and I know that I can change that in the config. Perhaps that is a solution for my problem, changing that amount of time. However, I expected this to be simpler because in your internals you already know if it will be able to sleep soon (you know the duration, delays and repeats of scheduled animations). As you said, If I add an onUpdate callback function to every animation, that might be a bunch of calls. 

Link to comment
Share on other sites

  • Solution

You could add that logic to your gsap.globalTimeline onUpdate method if it's really important to you to only run when there's an active animation. You could getChildren() and loop through and check isActive() or compare their startTime and endTime to see if they span the current time. As soon as you find one, break the loop and call your render method or whatever.

 

I think it's far better for you to do that with the existing hooks rather than adding more logic to GSAP to constantly run those checks on every single tick for all users even though probably less than 0.0001% would ever use that feature. See what I mean? It would force everyone to pay a price, but a tiny fraction of a percent would ever reap a benefit. 

  • Like 2
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...