1586096 - No need to compose transform animation on the compositor thread if we have animations on transform-origin

Status: NEW

(Core :: CSS Transitions and Animations, enhancement, P3)

Description

[Boris Chiou [:boris]]

Not sure if this is expected behavior. For example:

@keyframes anim {
  to {
    transform: rotate(45deg);
    transform-origin: 10% 90%;
  }
}
#target {
  animation: anim 5s;
}
<div id="target"></div>

In this case, we have an animation on transform and transform-origin properties. Basically, we run the transform animation on the compositor with a fixed transform-origin value by setting it into AnimationData. So if we have an animation on transform-origin, we should fall-back to the main thread, I think. However, I tried to dump the log to make sure this, and I notice that we run this animation on the main thread indeed, but we still pass transform animation to the compositor thread, so we still compose transform animation on the compositor thread. This means we compose transform animation on both the compositor thread and the main thread, but transform-origin only runs on the main thread. Although the rendering result is correct, it seems we don't need to pass transform animation to the compositor?
Or is this expected?

Comment 1

[Boris Chiou [:boris]]

I will close this if this is expected.

Comment 2

[Boris Chiou [:boris]]

It seems we add the animation into the compositor for each tick (because we reconstruct nsDisplayTransform), so we get the up-to-date transform-origin on the compositor, so does the rendering result.

Comment 3

[Hiroyuki Ikezoe (:hiro)]

I am pretty sure this is a bug.

Comment 4

[Hiroyuki Ikezoe (:hiro)]

What I suppose we should do is make transform-origin run on the compositor.

Comment 5

[Boris Chiou [:boris]]

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

What I suppose we should do is make transform-origin run on the compositor.

Agree.