Jump to content
GreenSock

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

x/y/z vs translate? Any difference?

Recommended Posts

Hi,

 

I just want to know if there is any difference in using say { x: "50px" } VS { css: { transform: "translateX(50px" }}, performance wise etc? Is x/y/z always better when it comes to positioning?

 

thanks

Link to post
Share on other sites

Hello jesper.landberg and welcome to the GreenSock forum!

 

Basically they would do the same thing. But by using "x" instead of "transform", is that by using " x" you guarantee that your translate will be animated cross-browser.

 

In your example above, depending if it is a WebKit based browser. You might need to add the prefix "-webkit-" to the "translate" property. So then you would have to write multiple tweens with different transform values, or use some browser check if statements. GSAP does all the heavy lifting behind the scenes, making sure the right CSS property gets applied depending on the browser.

 

So in the long run using the GSAP shorthand x,y, z will allow you to write less code, ensure cross browser compatibility, and make your life easier.

 

Does that make sense?

 

:)

  • Like 2
  • Thanks 1
Link to post
Share on other sites

Hey Jasper, looks like Jonathan answered this for you precisely.

 

I have also found that people are often confused between using x and xPercent.

 

Here's a short video explaining how each of them work and how they overwrite the default CSS styles.

 

 

Hope that helps.

  • Like 2
Link to post
Share on other sites

Great input so far, but I wanted to add another aspect that I think is very important...

 

Whenever you define a transform as a string like transform:"translateX(50px)", it must apply that to the element and then read back and parse the matrix() or matrix3d() that the browser creates. Why? Because that string could have any number (and order) of values in it, like transform:"translateX(50px) rotate(40deg) scale(0.5,0.5) translateY(100px) rotate(30deg)". Remember, according to the CSS spec, order of operation is important and you can string together a bunch of stuff (notice my example has two different rotate() values). All of those get mashed together into a matrix() or matrix3d(). My point is that it's a lot more work that way.

 

Using GSAP for transforms gives you a consistent order-of-operation which has many benefits, one of which is that we can further optimize for speed. So if you define x:50 instead of transform:"translateX(50px)", GSAP can just grab that one value and handle it independently without all the extra calculations. In short, there is a definite speed benefit from using our transform component aliases like x, y, z, scaleX, scaleY, rotation, etc. 

 

Another bad thing about defining transform:"..." is that you can lose rotational precision. The matrix that results from a rotation of 360 is the same as the one that results from 720 and 0 and 1440. It's impossible to extract the rotational data accurately when it goes beyond a full rotation. This has nothing to do with GSAP - it's the nature of matrices. However, if you use GSAP's built-in aliases, you always get perfect precision no matter how far you exceed 360 degrees in any direction. 

 

I'd strongly recommend ALWAYS using GSAP's built-in aliases for transforms unless you need a non-standard order-of-operation (which is very rare). 

  • Like 5
Link to post
Share on other sites

Really good explanation Jack for using GSAP's built in aliases for transforms, unless you need a non-standard order-of-operation. A very useful and need to know thing for working with transforms in GSAP. :)

  • Like 1
Link to post
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.

×