My two cents would be to use properties what they were intended for (so translateX/Y for 2D translations and translate3d for 3D translations).

I'm not an expert, but translate3d will force a GPU animation which is more resource-intensive and requires a separate render layer for each instance.

That's a fair point, maybe this should exist as an option in tailwind.config.js to toggle output between

translateX(var(--transform-translate-x)) translateY(var(--transform-translate-y))

and

translate3d(var(--transform-translate-x), var(--transform-translate-y), 0)

Although I'd argue that the translate utility classes would almost always be used in conjunction with transition and be triggered by user input. It's fairly common practice to use translate3d to ensure smooth transitions for things like hover effects and showing modals/panels, even though they are just transforms in the X and Y planes.

translate3d does force GPU rendering, but it's 2020 and Tailwind is a framework for building modern UI, so it's safe to assume the majority of devices being targeted are more than capable of handling it.

Gathering some feedback here then can decide if we should merge this 👍

https://twitter.com/adamwathan/status/1280902295081926656

Commenting here as well for those that don’t see the Twitter thread.

This link compares performance for both translate3D and translateX/Y. At least on mobile, translate3d is around 7% slower. The most recent revision to the test was on in October last year.

https://jsperf.com/translate3d-vs-xy/147

I would just use translateX/Y; since relying on hardware acceleration is not always a good thing. However, it could be an opt-in feature. My idea is something like:

<div class="enable-gpu">
    <div class="transform translate-y-6">
</div>

.enable-gpu { 
  transform: translateZ(0); /* equivalent to translate3d(0, 0, 0) */
}

Some developers might prefer a toggle in tailwind.config.js, like @slavanossar mentioned, but a global toggle might not be the best for everyone. Maybe we could have both?

This is an important consideration as well (caused by the GPU rendering things differently): https://twitter.com/krijassnica/status/1280909655879880704. More information here: https://frippz.se/2016/02/04/fixing-blurry-text-on-hardware-accelerated-elements/

Lastly, like Donald Knuth stated: "premature optimization is the root of all evil". 🙂

I think having both would be a bad idea. Tailwind is nice for its defaults, and people can always extend the config as they wish.

Intel(R) Core(TM) i7-8705G CPU
ATI Polaris 22 XL [Radeon RX Vega M GL] + Intel HD Graphics 630
Ubuntu 5.4.0-40-generic

I came across such an issue because I wanted to move a big background-image with transform: background-position. Turns out to be a very bad idea, it stutters and the browser couldn't handle it. Tried translateX/translateY, but there was some stutter left, but better performance in general.

I got it completely fixed with transform3d and the will-change property, because of hardware acceleration with transform3d and performance optimizations with will-change.

Good article about will-change
https://css-tricks.com/almanac/properties/w/will-change/

Having thought about this some more, I think this would be better solved by just having a transform-gpu utility that replicates the existing transform but uses translate3d() instead. Up to the maintainers if they want to add it, pretty simple for us to add as our own custom utility. I think a lot of people would find it useful though.

For anyone who wants to create their own:

/* utilities.css */

.transform-gpu {
  --transform-translate-x: 0;
  --transform-translate-y: 0;
  --transform-rotate: 0;
  --transform-skew-x: 0;
  --transform-skew-y: 0;
  --transform-scale-x: 1;
  --transform-scale-y: 1;
  transform: translate3d(var(--transform-translate-x), var(--transform-translate-y), 0) rotate(var(--transform-rotate)) skewX(var(--transform-skew-x)) skewY(var(--transform-skew-y)) scaleX(var(--transform-scale-x)) scaleY(var(--transform-scale-y));
}

EDIT: changed 3d to gpu, since it could imply the existence of translate-z utilities and get confusing.

Since you are using translate3d, you could define variables for the z axes to the transform property as well.

.transform-gpu {
    --transform-translate-x: 0;
    --transform-translate-y: 0;
    --transform-translate-z: 0;
    --transform-rotate: 0;
    --transform-skew-x: 0;
    --transform-skew-y: 0;
    --transform-scale-x: 1;
    --transform-scale-y: 1;
    --transform-scale-z: 1;
    transform: translate3d(var(--transform-translate-x), var(--transform-translate-y), var(--transform-translate-z))
        rotate(var(--transform-rotate))
        skew(var(--transform-skew-x), var(--transform-skew-y)) 
        scale3d(var(--transform-scale-x), var(--transform-scale-y), var(--transform-scale-z));
  }

I've added scale3d() and it uses shorthand methods where possible.

Really like the idea of a separate .transform-gpu class 👍 if you'd like to update the PR to use that implementation I'm happy to merge it @slavanossar.

@adamwathan Done, thanks!

Awesome thanks!