Jump to content
Search Community

gsap.set and gsap.to different beaviour ?

ninmorfeo test
Moderator Tag

Recommended Posts

Well I had another question to ask but before I got there I got stuck first.

In this post I have 2 questions to ask.

The first one: why do gsap.set and gsap.to have different behaviors regarding the same function?

I read in the docs that gsap.set is nothing more than a gsap.to with duration 0, but if you try to drag a card from the curve to the drop area you will see that the final positioning is different (you can swipe gsap.to and gsap.set with the button on the left).

 

The second question is: why do it give me a error when I try to copy the transformations of one of the cards on a dynamically created object?

You can test and watch the console by clicking on a draggable card and then on the button on the left 'clone object' (the function that manages cloning is at the end of the code).

See the Pen RwNqJdm by Ninmorfeo (@Ninmorfeo) on CodePen

  • Thanks 1
Link to comment
Share on other sites

The reason the set() and to() are behaving differently is because of the order in which you're calling kill() on the Draggable. Since Draggable controls the x and y properties of the element, when you kill() the Draggable it also kills any tweens of x and y on that element (in case any were created, like due to throwing/inertia). If you simply move your this.kill() call to BEFORE you create your to() tween, it'll work as you expected.

 

As for the cloning error, that's due to a bug related to setting the "transform" property specifically (which is very uncommon and we usually recommend against because it's better to set specific properties like x, y, rotation, etc. to ensure that everything is cached and rotational data is extracted properly, because browsers report transform data as matrix() and matrix3d() which are inherently ambiguous when it comes to rotational data). This bug is fixed in the upcoming release, due out later this week, which you can preview at https://s3-us-west-2.amazonaws.com/s.cdpn.io/16327/gsap-latest-beta.min.js

 

Does that resolve things for you?  

  • Like 2
Link to comment
Share on other sites

12 hours ago, GreenSock said:

Sure, you're welcome to use that file if you'd like. But I do hope to push 3.1.0 out within the next 2 days so hopefully you won't have to wait long. 👍

 

I dont know if i found another bug, but if i try to concatenate an animation after cloning object, you can see that this object created dont go at center of drop zone, like if transform-origin was ignored....can you do check please?  i added function at the end of previous script pen
To replicate: drag card in space then click on clone element button.

Link to comment
Share on other sites

No, these are not bugs. This actually shows exactly why we recommend NOT using the generic "transform" property, and instead you should use the components like x, y, scale, etc. When you set "transform", it could have an unlimited sequence of transforms in that string, so the only option is for GSAP to apply that and then read the matrix()/matrix3d() from the browser and decompose it into the pieces (x, y, scaleX, scaleY, rotation, etc.). The matrix()/matrix3d() that the browser provides is ALWAYS px-based. All %-based values are lost, and rotations are ambiguous (rotate(0deg) is the same as rotate(360deg) and rotate(720deg), etc.). You had some %-based values in the "transform" that you're copying, but those get combined with the normal px-based ones in the resulting matrix()/matrix3d(). And remember, GSAP recognizes special xPercent and yPercent values as well but you forgot to set those. In other words, you should do this: 

 

gsap.to('#'+oggetto_id, {
          duration: 2,
          x: x_pos,
          y: y_pos,
          xPercent: -50, //<- IMPORTANT!
          yPercent: -50, //<- IMPORTANT!
          boxShadow: '-2px 2px 5px 0px rgba(0,0,0,0.5)',
          scale: 0.8,                        
          borderWidth: 0          
});

Because your other element (that you're cloning) has those values offset as such. 

 

In other words, GSAP correctly reported and applied the raw "transform" to match the overall appearance/positioning, but it was impossible to know that PART of the x/y values were percentage-based transforms (they were all combined into px-based ones). 

 

Does that clarify things? 

 

Again, I'd recommend using the GSAP-optimized transform component properties like x, y, xPercent, yPercent, scaleX, scaleY, rotation, etc. to avoid ambiguities and maximize performance. 

  • Like 2
Link to comment
Share on other sites

ok I understand my issue about transformations.

How should I behave with the scale instead? use scaleX and scaleY instead of generic scale?
because if you have noticed, in the code if I set the scale to 1 instead of 0.8 which is the one set by the transformation, the animation does not start

Link to comment
Share on other sites

11 minutes ago, ninmorfeo said:

because if you have noticed, in the code if I set the scale to 1 instead of 0.8 which is the one set by the transformation, the animation does not start

 

6 minutes ago, ninmorfeo said:

ok working with scaleX and ScaleY ...thanks a lot boss!

I don't think it has anything to do with scaleX/scaleY - it's due to the fact that you forgot to put xPercent:-50, yPercent:-50, right? 

  • Like 1
Link to comment
Share on other sites

yes what you say is used to align the object with respect to the cards that have the translate set to 50%.

I was referring instead to the animation that from scale 0.8 had to become 1.

I saw that if I use scale: 1, the animation does not start, if instead I separate them with scaleX and scaleY it works correctly.

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