Jump to content
GreenSock

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

Did immediateRender break? 3.0.1 -> 3.2.2

Recommended Posts

Updated from 3.0.1 to 3.2.2 and now my stuff isn't rendered before play() is called.

 

Example code:
 

tl = gsap.timeline({ 
  paused: true,
  defaults: {
    immediateRender: true
  }
})
.set(parent, { overflow: 'hidden' })
.from(child, { yPercent: 100 }, 0}

setTimeout(() => { tl.play() }, 2000)

 

Link to comment
Share on other sites

6 hours ago, ZachSaucier said:

Hey Jesper.


It seems fine to me: 

 

Can you please produce a minimal demo reproducing the error?

 

It's super weird, immediateRender is deffo not happening (or well it looks like it isn't) on any timeline on the whole site i'm building. Reverting back to 3.0.1 makes it work tho.

 

Didn't update my splitText plugin tho, not sure if that can have some side-effects on things? But it's just not on split animations. Anyway, il try to see if I can reproduce it later on a pen or something.

Link to comment
Share on other sites

1 hour ago, jesper.landberg said:

il try to see if I can reproduce it later on a pen or something.

Please do! We want to fix any bugs that exist ASAP.

Link to comment
Share on other sites

3 hours ago, jesper.landberg said:

It's super weird, immediateRender is deffo not happening (or well it looks like it isn't) on any timeline on the whole site i'm building. Reverting back to 3.0.1 makes it work tho.

I'm super curious about this and I'm eager to see a reduced test case. I can't seem to reproduce the issue either but I'm sure I'm just missing something and once we see the reduced test case it'll become clear. 

 

I'm confident it has nothing to do with SplitText.

 

@jesper.landberg I did do a bunch of work to fix some complex timeline-related timing issues in recent updates so I wonder if there's something in there that caused an unintended side effect. But again, all my tests seem to be passing. If you're seeing different behavior in early 3.x versions, it was either a bug that got fixed or (more likely since you're more of an advanced user) it's a pesky new one that needs squashing which I'd like to do promptly, so any help you could offer would be fantastic. 

Link to comment
Share on other sites

35 minutes ago, GreenSock said:

I'm super curious about this and I'm eager to see a reduced test case. I can't seem to reproduce the issue either but I'm sure I'm just missing something and once we see the reduced test case it'll become clear. 

 

I'm confident it has nothing to do with SplitText.

 

@jesper.landberg I did do a bunch of work to fix some complex timeline-related timing issues in recent updates so I wonder if there's something in there that caused an unintended side effect. But again, all my tests seem to be passing. If you're seeing different behavior in early 3.x versions, it was either a bug that got fixed or (more likely since you're more of an advanced user) it's a pesky new one that needs squashing which I'd like to do promptly, so any help you could offer would be fantastic. 

 

I think this illustrates my issue. the defaults immediateRender doesn't seem to apply on the .set? is this correct behaviour? Have I missed something about this in the release docs maybe?:) 

See the Pen 0b7cfd3fd2f0e15ffd381920c4701048?editors=0010 by ReGGae (@ReGGae) on CodePen

Link to comment
Share on other sites

17 minutes ago, jesper.landberg said:

the defaults immediateRender doesn't seem to apply on the .set? is this correct behaviour? Have I missed something about this in the release docs maybe?

A .set() is always immediate, it doesn't matter about immediateRender. I get the same behavior on your pen with all versions of GSAP (2 and 3). 

 

The reason for this is that your timeline is paused, which means it never started, not even a little bit. That means that the .set() call (and all parts of your timeline) is not reached because the timeline's progress is not greater than 0.

 

You could force the timeline to start a tiny bit by using tl.seek(0.001); or something like that which could be necessary depending on the exact effect that you need (though I can't imagine a scenario where it'd be necessary given you can use repeatRefresh), but more commonly you just use a regular .set() call outside of the timeline and then do your animations in the timeline:

See the Pen OJVmGWp by GreenSock (@GreenSock) on CodePen

 

Does that make sense?

Link to comment
Share on other sites

10 minutes ago, ZachSaucier said:

A .set() is always immediate, it doesn't matter about immediateRender. I get the same behavior on your pen with all versions of GSAP (2 and 3). 

 

The reason for this is that your timeline is paused, which means it never started, not even a little bit. That means that the .set() call (and all parts of your timeline) is not reached because the timeline's progress is not greater than 0.

 

You could force the timeline to start a tiny bit by using tl.seek(0.001); or something like that which could be necessary depending on the exact effect that you need (though I can't imagine a scenario where it'd be necessary given you can use repeatRefresh), but more commonly you just use a regular .set() call outside of the timeline and then do your animations in the timeline:

 

Does that make sense?

I see, have this behaviour changed since 3.0.1 then? Just found it a bird weird that everything went crazy after updating without touching the code:P

Link to comment
Share on other sites

4 minutes ago, jesper.landberg said:

have this behaviour changed since 3.0.1 then?

Nope. It could be a different issue? But you can switch out the version in your pen - the behavior is the same all the way back to GSAP 2 like I said.

Link to comment
Share on other sites

Yeah, if your code is running very differently since 3.2.2, I suspect there is something else at play here, @jesper.landberg. Is there any chance you could provide a reduced test case that illustrates DIFFERENT (undesirable) behavior in 3.2.2 than earlier versions? I've got my bug-fixing hat on and I'm in attack mode...bring it on! ;)

Link to comment
Share on other sites

Aha! I think I found what you were talking about, @jesper.landberg. It was a tricky thing with immediateRender and order-of-operation but it should be fixed in the next release which you can preview at https://s3-us-west-2.amazonaws.com/s.cdpn.io/16327/gsap-latest-beta.min.js

 

Would you mind trying that in your project and verifying that it's working well for you now? Sorry about any confusion there - it was very difficult to reproduce but with enough attempts I managed to stumble across it. :)

  • Like 3
Link to comment
Share on other sites

  • 2 weeks later...
On 2/29/2020 at 8:11 AM, GreenSock said:

Aha! I think I found what you were talking about, @jesper.landberg. It was a tricky thing with immediateRender and order-of-operation but it should be fixed in the next release which you can preview at https://s3-us-west-2.amazonaws.com/s.cdpn.io/16327/gsap-latest-beta.min.js

 

Would you mind trying that in your project and verifying that it's working well for you now? Sorry about any confusion there - it was very difficult to reproduce but with enough attempts I managed to stumble across it. :)

 

Hey sorry for the late reply. But yes after updating to the latest version all my issues seem to be gone:)

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