Incorrect start time when replacing a transition on the compositor if the main thread is busy
Categories
(Core :: CSS Transitions and Animations, defect)
Tracking
()
People
(Reporter: boris, Unassigned)
References
(Blocks 1 open bug)
Details
Attachments
(1 obsolete file)
When writing this reftest, I noticed we didn't send the correct start time to the compositor, so we skip the delay phase (because we compute the incorrect elapsedDuration) after replacing the transition
<!DOCTYPE html>
<html class="reftest-wait reftest-no-flush">
<style>
#target {
width: 100px;
height: 100px;
background: green;
transition: transform 100s 1s steps(1, start);
}
</style>
<body>
<div id='target'></div>
</body>
<script>
document.addEventListener('MozReftestInvalidate', () => {
// The first transition: 0px -> 100px.
target.style.transform = 'translateX(100px)';
target.addEventListener('transitionstart', () => {
const startTime = performance.now();
while (performance.now() - startTime < 1200);
target.addEventListener('transitionrun', () => {
document.documentElement.classList.remove('reftest-wait');
}, { once: true });
// The second transition: 100px -> 200px.
target.style.transform = 'translateX(200px)';
}, { once: true });
});
</script>
</html>
|
Reporter | |
Comment 1•1 year ago
|
||
|
|
Reporter | |
Comment 2•1 year ago
|
||
We did pass this test few years ago, so this may be another regression I think.
|
|
Reporter | |
Updated•1 year ago
|
|
|
Reporter | |
Comment 3•1 year ago
•
|
||
Basically we align the start time with mPendingReadyTime. So when we send the transition info to the compositor, the animation has run for a while if the main thread is busy, and so the "start time"/"ready time" is behind the current time a little bit (and it is noticeable). Therefore, this may cause the transition jump a little bit, even if we recompute the start value or set start value by the last value on the compositor.
I guess the gap between ready time and real start time on the compositor becomes huge since we removed the PendingAnimationTracker (especially for busy main thread), and so we may still need more tweak on it. However, I have no idea for now.
|
|
Reporter | |
Comment 4•1 year ago
|
||
We'd like to fix this together with Bug 1626165.
|
||
Updated•1 year ago
|
Description
•