Jump to content
GreenSock

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

staggerFrom on resize problem with positioning and rendering using autoAlpha

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 have a grid of thumbnails (6 columns / 5 rows) that I'm animating on load and resize. 

 

On load the columns stagger from left to right into the page. On resize the rows stagger down off the page, and then the columns re-enter from left to right. The number of columns, rows, tn size and position are based on window width and aspect ratio.

 

I'm using autoAlpha to hide/reveal column 6 and row 5. 

The code/conditions for the rows are working as expected.

 

The problem I'm having is with column 6 on "resize only".

 

6 cols if window width >1200px

5 cols if window width <= 1200px

 

If 6 cols enter on "load" everything works always as expected. When resizing ww <=1200px, grid exits down, then 5 cols re-enter from left (col 6 hidden). Then if you resize ww >1200px, grid exits down, then 6 cols re-enter from left. Everything works fine no matter how many times the ww is resized.

 

If 5 cols enter on "load" there is a problem with col 6 on "resize". When resizing ww >1200px, grid exits down, then col 6 becomes immediately visible in it's end "x" position (farthest right) and the remaining 5 cols re-enter from left. Column 6 should become visible "but" positioned off the page to left, then stagger in with the other 5 cols.

 

My thinking is the autoAlpha event is firing before being positioned, even though it is called within the positioning function. I have tried putting autoAlpha at the end of a TimelineLite timeline, used a positive position offset, etc, mostly with worse results.

 

I have also tried staggerTo using an x start position -(ww+500). They position and size correctly but for some reason they don't enter into the page using a variable ie: "+=ww+500" but it does work with just a number within the string "+=1400". If I use the staggerTo method I can't use a fixed number if I use a variable for the starting negative offset. If I do use a fixed number that will insure that the grid clears all different window widths ie: -3000px, the entrance speed won't be consistent across different window widths.

 

I've uploaded copies of the files (the tn images have been replaced with solid colored jpgs)

 

http://www.peterdavidian.com/gsap/staggerFrom.html

 

I've searched the JS forums but couldn't find a post with a solution. It's been days now (really almost a week) and I need someones help!

 
Thank you, Peter
 
 

My functions:

dLoad:  sizes and positions the grid container

tSz:  sizes the tn's

tPos:  sizes and positions the number of cols and rows

tEnterR:  staggers the cols in from left

tExitD:  staggers the rows down, then calls tReEnterR

tReEnterR:  calls tSz and tPos then staggers cols in from left

Link to comment
Share on other sites

Hi and welcome to the GreenSock forums.

 

First, great job so far. It seems a lot is working very well. 

 

It took me a awhile to follow exactly what is happening and what is wrong.

 

The main problem as I see it is in the following use case.

 

Browser window starts narrow (five cols).

User resizes window to width that would accomodate 6 cols.

 

Upon resizing wider, the rows animate out properly but the 6th column does not animate in properly. It just appears suddenly.

 

From my tests, the code that is supposed to stagger in the 6th column is simply not firing when it should.

 

Add these console.logs to the function below:

 

function tReEnterR(){


tSz();
tPos();


tl = new TimelineLite();


if ((wh/ww) > 0.5 && ww <=1200)
{
console.log("animate in column 5");
tl.staggerFrom([c5,c4,c3,c2,c1], .8, {x:-ww, ease:Power2.easeOut}, 0.1);
}
else if ((wh/ww) > 0.5 && ww > 1200 || (wh/ww) <= 0.5)
{
console.log("animate in column 6");
tl.staggerFrom([c6,c5,c4,c3,c2,c1], .8, {x:-ww, ease:Power2.easeOut}, 0.1);
} 
}

When I expected the "animate in column 6" to appear, I only saw "animate in column 5".

 

Its my best guess that something is not quite right in your conditional code.

 

Let me know if this puts you in the right direction. 

 

 

  • Like 1
Link to comment
Share on other sites

Carl, U 'Da Man!

 

Thanks for pointing me in the right direction.

 

Faulty logic was the culprit. A combination of missing and/or unneeded conditions, and some inaccurate operators.

 

The conditions in the animation functions were unnecessary. By modifying, deleting and adding conditions it works like a charm. In the code above I removed the conditions and the 5 column timeline. Now all 6 columns always animate in, with column 6 being hidden with autoAlpha as it was intended.

 

Added some other console.logs and updated the files. You can see it here: http://www.peterdavidian.com/gsap/staggerFromSolved.html

 

Don't know why I waited so long to get help. Next time I'll reach out to the community, instead of banging my head against the wall.

 

Thanks you again, so much!

 

Peter

  • Like 1
Link to comment
Share on other sites

Very happy to hear I was able to help you figure it out. It appears to be running very nicely now.

 

I have to say, this is a wonderful experiment you have going here. I imagine your goal is to have a fully responsive animated site built. As you can see it is a bit of a challenge to account for all the different screen-size breakpoints when it comes to animation. Lots of factors to consider. 

 

I think this bare-bones demo you have built does an excellent job of illustrating

 

1) the basic mechanics and logic involved in your custom code to make it all work

2) that GSAP does quite a bit to make this sort of thing possible

 

In short, I think a lot of folks can benefit from seeing how you approached this. Great job.

 

Best of luck with this project as it moves forward. Let us know if you hit any rough spots along the way.

 

Carl

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