This may be a regression after introducing compositor animations for individual transforms.
For example:

@keyframes rotate {
  to { rotate: 1 1 0 360deg; }
}
.circle {
  width: 100px;
  height: 100px;
  border-radius: 50%;
  transform-origin: 50% 50%;
}
#target {
  background: green;
  translate: 400px;
  animation: rotate 5s linear forwards;
}

<div id='target'></div>

Expected result: The element should be running animations something like this:

@keyframes rotate {
  from {
    translate: 400px;
    rotate: 1 1 0 0deg;
  }
  to {
    translate: 400px;
    rotate: 1 1 0 360deg;
  }
}

Actual result: It seems the animation on rotate property overrides the translate property.

We may need to fall back to the main thread animation in this case.

Updated: Use base style to pass the other transform-like properties to the compositor

I don't think we need to run such animations on the main thread, we can just pass the translate in question to the compositor just like a base style.

(In reply to Hiroyuki Ikezoe (:hiro) from comment #1)

I don't think we need to run such animations on the main thread, we can just pass the translate in question to the compositor just like a base style.

Oh yes. Sounds good. I'd try this way. Thanks.

Looks like this is a severe bug right now because it's likely that people use <transform> together with <translate>, <rotate>, <scale>. And want to create animations only on some of them. (I missed this case ;( )

If we want to pass the non-animating style (e.g. <transform>, <translate>, or even <offset-path>) to the compositor like a base style, it seems we have to check all transform-like properties every time (with/without animations), and then pass those, with "animations" or "base style", to the compositor. The compositor needs to do interpolation for those with animations or do nothing for those which only have base style, and then merges these information all together to generate the final matrix.

So we can use StaticPrefs::layout_css_individual_transform_enabled() in
the next patch.

Not only animating transform-like properties, but also non-animating ones have
to be passed into the compositor, so the final transform matrix could
take them into account (on the compositor).

https://hg.mozilla.org/mozilla-central/rev/83bd68a2767e
https://hg.mozilla.org/mozilla-central/rev/2b90bc2a97f4

Is this something we should consider for Beta uplift or can it ride the trains?

(In reply to Ryan VanderMeulen [:RyanVM] from comment #9)

Is this something we should consider for Beta uplift or can it ride the trains?

Nope. Individual transform has a pref which is disabled by default. So we don’t need to uplift this for now. Everything should be fine without this patch on beta and release. Thanks.