Closed Bug 1555548 Opened 7 months ago Closed 6 months ago

Incorrect results of individual transforms when some transform-like properties are running animations but others not

Categories

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

defect

Tracking

()

RESOLVED FIXED
mozilla69
Tracking Status
firefox-esr60 --- unaffected
firefox67 --- unaffected
firefox68 --- disabled
firefox69 --- fixed

People

(Reporter: boris, Assigned: boris)

References

(Regression)

Details

(Keywords: regression)

Attachments

(3 files)

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

Component: Layout → DOM: Animation
Component: DOM: Animation → CSS Transitions and Animations

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.

Assignee: nobody → boris.chiou

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

See Also: → 1557437
Pushed by bchiou@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/83bd68a2767e
Move pref into StaticPrefList. r=hiro
https://hg.mozilla.org/integration/autoland/rev/2b90bc2a97f4
Send other transform-like properties as non-animating animation into compositor. r=hiro
Status: NEW → RESOLVED
Closed: 6 months ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla69

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

Flags: needinfo?(boris.chiou)
Flags: in-testsuite+

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

Flags: needinfo?(boris.chiou)
Blocks: 1424900
No longer blocks: 1506939
You need to log in before you can comment on or make changes to this bug.