Jump to content
Search Community

Truly responsive Animations

katerlouis 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

This discussion started in another thread and definitely deserves one for itself; you better read the last 4-5 posts in this thread:

 

 

TL;DR:

Complex animations with attention to detail would basically need to be recalculated completely, when the browser gets resized.

Not only does the layout jump and px values must be recalculated, but as the distances on the screen change, durations, timings, offsets need to change aswell in order to create a similar affect than before. Certain html-elements may drop entirely on new breakpoints and therefore don't need to be tweened, leaving a timing hole in the chain.

 

This is not an easy task and complicates things quite a lot (for me atleast–) 

 

Blake made a pen with a possible setup for recalculations on resize:

 

See the Pen jLLqbY by osublake (@osublake) on CodePen

 

Doing this work for 50+ animations screams "have fun maintaining this code" to me. 

 

A few questions:

 

1) Could you walk us briefly through the code, Blake? I can't quite follow the forEach loop through the media queries, and especially not the code in "onMediaChange()"

 

2) I treat most of my modules individually, meaning each module gets it's own breakpoints for what the situation demands. Basically "Code the first layout-step, resize the browser and look how long this works out nicely" – if that means we have 3 media-queries in the range of 1280 down to 1050, so be it.

Is there any way GSAP / JS in general could react to the breakpoints declared in CSS or do I simply have to hardcode those same breakpoints in JS?

 

You know what I'm about to ask, don'tya? :F

3) Is there any way to stuff the things Blake did there into a neat lil box, and let the developer access it like this for instance:

 

var responsiveTween = TweenMax.responsive({
	"(max-width: 601px)": TweenMax.to(...),
  	"(max-width: 801px)": TweenMax.to(...),
  	"(max-width: 1024px) AND (min-aspect-ratio: 16/9)": TweenMax.staggerFromTo(...),
	"fallback": TweenMax.to(...)
})

 

Okay, .. while writing the code I realized this is not a pretty solution. But you see what I'm aiming at, right?

A solution that doesn't require you to write helper functions yourself and fits nicely in the GSAP workflow / ecosystem.

 

Let's get crazy for a moment: How about debouncing the resize event and then animate between these the two breakpoints to make a seamless transformation? I feel this would be insanely complicated and only work flawlessly in very few situations, so maybe forget about that ^^

  • Like 1
Link to comment
Share on other sites

I don't think there is a silver-bullet solution for resizing complex animations.

You can't have a complex animation with precise layout in a 16:9 aspect ratio and then expect some magic to happen when you go to 9:16 (landscape to portrait) to have it all work seamlessly.

 

As Blake said in his previous post, in addition to worrying about the new position of elements, if you're going to do it "right" you also have re-calculate the duration of all the animations so that you don't have radically different speeds of things moving. 

 

I have yet to see an approach that works better than the ol' "rebuild the animation with new parameters when you need to". 

 

Thanks for the API suggestions. After a moment of consideration it doesn't seem quite feasible to create an API for that any time soon. We're really busy on other features and updates but perhaps we can regroup and consider possible solutions after the next big release. 

 

Happy Tweening!

 

  • Like 2
Link to comment
Share on other sites

1 hour ago, Carl said:

You can't have a complex animation with precise layout in a 16:9 aspect ratio and then expect some magic to happen when you go to 9:16 (landscape to portrait) to have it all work seamlessly.

 

I don't expect one tween it to adapt like magic. 

Defining multiple animations per breakpoint is exactly what I want, but all the code surrounding that is really expensive.

That's why I am looking for an API.

 

But I understand that you guys have other things with higher priority at the time. 

 

That being said, I'd like to hear more about that and how others deal with these problems.

 

 

What I've come up with to tackle this is tweening css vars like `--progress` and let the css handle different layouts reacting to this `var(--progress)`

But this approach gets you only so far.

Link to comment
Share on other sites

3 hours ago, Carl said:

I don't think there is a silver-bullet solution for resizing complex animations.

You can't have a complex animation with precise layout in a 16:9 aspect ratio and then expect some magic to happen when you go to 9:16 (landscape to portrait) to have it all work seamlessly.

 

There's definitely not going to be silver bullet for really complex stuff and I don't think most would be looking for a magic solution for radical aspect changes, realistically you should be designing different solutions for desktop and mobile/portrait. 

 

I think it's more about finding some best practices for updating animation to handle reasonable changes in screen sizes. i.e. someone might drag a window from 1400px to 1600px and changes aspect from 16:6 to 16:10 if they make it taller sort of thing. Typical user adjustments to screen size. 

 

Do we use invalidate to try and reboot the the values, maybe pass the animation through the modifierPlugin, what techniques have people used?

Link to comment
Share on other sites

Well there's a lot of different approaches to this. It really depends on what the animation does, and what it's being used for.

 

If an animation runs continuously, the ModifiersPlugin might be a good option. Remember that you can change the timescale of an animation, allowing you to change the speed on the fly.

  • Like 1
Link to comment
Share on other sites

Here's an idea I've had rolling around in my head since Zirkels previous post about transforms. It demonstrates 2 concepts I had. 

 

First it uses modifiers to adjust transform based animations responsively.

 

Second it animates transforms on an object relative to the window or its parent (rather than the object itself)  depending on the parameter passed allowing you to treat them like top left percentage animations, effectively making the parent a stage which I think is really useful. 

 

If you open the pen and drag around the window size you'll see it work. Interested to know if people think this is a good solution or if there is a more efficient way to handle this, I don't know how performant it would be with large complex animations but I can certainly put it to work for the more modest UI based stuff I do.

 

 

 

See the Pen Jvpdpz by Visual-Q (@Visual-Q) on CodePen

 
Second pen adds function with event handler to maintain responsive transforms after animation ends.
 

See the Pen NMyxaK by Visual-Q (@Visual-Q) on CodePen

 

Link to comment
Share on other sites

14 minutes ago, OSUblake said:

Maybe something like this.

 

That's awesome I was trying to work out how to improve it by limiting the calculations to resizes but didn't get my head wrapped around it.

 

Question what is the tween.ratio value in the modifiers?

  • Like 1
Link to comment
Share on other sites

Here's a second run at this with @OSUblake's invaluable assistance moving the resize calculations into an event handler outside of the modifiers.

 

I realized, dufus that I am, that the original had a whole bunch of extra calculations of the object's size that were unnecessary all you had to do was calculate the parent's size.

 

So here's my revised effort for Responsive Transforms Based on Parent ( in this case the Window). 

 

Note I added in the divide by 100 in the function to allow for the tween x and y to treat 100 as 100% percent of the parent/window size. Otherwise 1 would represent 100%. It can certainly be removed to reduce the calculations if you want to work with values of  0-1 instead of 0-100.

 

See the Pen OZQEZX by Visual-Q (@Visual-Q) on CodePen

 

  • Like 5
Link to comment
Share on other sites

13 hours ago, Acccent said:

Really interesting that modifiers is another way to avoid "caching" values!

 

Yeah this was one thing I thought modifiers might be good for back when it was first proposed I just never got round to testing it out till now. I think it's a pretty good option for this kind of thing as long as you don't push it to the point where the added load from using the modifiers degrades the animation performance. 

 

I also really like the option from @OSUblake's post referenced at the beginning of this thread that records the animation progress then rebuilds it.

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