Jump to content


Properties in .set() not being set at same point in time

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

I have an animation that is supposed to start the element off at a particular possession view .set(), and then animated it to a new position via .to().


Currently, if I reload the page many times, perhaps 1 out of 7 times the item starts from x=0, y=0 instead of the values to which I have set it.


The element starts out with display: none by default.


I tried (in pseudo code):



.set({x:1400, y:700, display: block, immediateRender: true})

.to({x: 1000, y: 600})



.set({x:1400, y:700, immediateRender: true})

.set({display: block})

.to({x: 1000, y: 600})


This is part of a larger animation system and very hard to extract a minimal case. But there is no code that should interfere with GSAP.


The strange thing is, it seems to be a timing issue. And if the CPU is busy it seems to be more likely to happen.


Are you doing some internal optimizations that stop the .set() command from getting executed all at the same time? It seems as if the display:block is executed before the updates to the x and y positions.


hanks fro any help you may be able to give.


Link to comment
Share on other sites

Please note that logging out $(element)[0]._gsTransform shows the correct values for x and y, while the visual position of the item is as if x =0 and y = 0.

Link to comment
Share on other sites

hmm, that's a strange one, especially since the _gsTransform values are being properly set (thanks for confirming that).


Is this behavior any more prominent in any particular browser?


Have you tried using fromTo() and seeing if that behaves any differently?




.set({x:1400, y:700, display: block, immediateRender: true})
.to({x: 1000, y: 600})
.fromTo(obj, 1, {x:1400, y:700, display:"block"}, {x:1000, y:600, display:"block"})

FWIW you shouldn't have to do that, but I'm just curious if it works any differently.


Also, I'm sort of grasping at straws here, but try throwing in


Right after you have declared all your animations, most likely immediately after all your initialization functions have run.



  • Like 1
Link to comment
Share on other sites

I think there are other animations being thrown onto the timeline as part of the animation system, pre-empting these.


I am looking further into it and might have to implement an FSM for the animation system as well, to make it graph-driven instead of linear.


I will let you know how it works out and if this was really the issue.

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.