Jump to content

Search In
  • More options...
Find results that contain...
Find results in...

Modifiers on steroids

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

Using the modifiers plugin I often thought about how cool it would be to have access to more than one variable at the same time. How could this be achieved in a way that would be simple to understand?


I think this syntax would be cool:

    "x,y,rotation":function(x,y,rotation,target) {
       return {
         // Doesn't make much sense, but ... the possibilities!
         x:rotation > 90 ? x : -x,
         rotation:rotation % 90 + x*y

The modifier function would be automatically passed the variables defined in the key (x,y,rotation in this case) and then the target object and return them as an object.
And then, added to that, bind "this" in the modifier-function to the TweenLite-Object so you can access stuff like this.progress()


But otherwise... isn't it a little bit overkill? And who would really need something like this?

Link to comment
Share on other sites

Thanks for posting this. I had a similar idea, but as a comma-delimited string. 



I like your idea better though. For some calculations, particularly when x, y, and rotation are involved, you need to know all the values at the same time, like this demo...

See the Pen qNPBpJ?editors=0010 by osublake (@osublake) on CodePen


Your idea would also work well for snapping in Draggable. There have been many times where I have needed the x and y values at the same to make a determination.



Link to comment
Share on other sites

I can totally see why this would be helpful in certain situations. It's a cool idea, but it's non-trivial to implement in a performant way internally. We put a HUGE priority on performance, but this type of functionality essentially forces properties to wait for others to update, gather them together, feed them to your function, then parse the results, etc. It'd be costly due to extra logic we'd have to add to the core rendering method, meaning every tween would be affected. You wouldn't notice any difference unless you're animating hundreds of properties simultaneously, but some projects require that so we are very careful about sacrificing performance like that for a feature that a tiny fraction of people would ever use (and could already accomplish with an onUpdate, albeit in a less convenient way). 


Thanks for sharing the idea, though. We love hearing stuff like this from users. It helps us stay in touch with what people in the trenches want/need. I'll keep chewing on this, though, and maybe I can come up with a way that wouldn't be so costly. 


Happy tweening!

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