Closed Bug 1776077 Opened 2 years ago Closed 2 years ago

Need to reset the sampled animation if it goes back to before phase (with a null progress)

Categories

(Core :: CSS Transitions and Animations, defect)

defect

Tracking

()

RESOLVED FIXED
107 Branch
Tracking Status
firefox107 --- fixed

People

(Reporter: boris, Assigned: boris)

References

(Blocks 2 open bugs)

Details

Attachments

(4 files)

For scroll animations, it's possible to go from the active phase to before phase, and the progress becomes null. However, we skip the sampling of this animation on the compositor, so we don't reset or remove this sampled animation in time.

e.g.
animation-duration: 10s;
animation-delay: 10s;

Based on the normalized result, we go into active phase when scrolling to 50% of the scroll range. However, if we scroll it back to 49%, this animation shouldn't have effect if the fill is none. The current implementation of compositor animation just skips this animation if its progress is null (code). It's not correct because skipping this animations doesn't reset it, so it may be still in effect for a while before the next transaction.

Perhaps we have to introduce a new SampleResult for this case.

It's unfortunate we still pass the test in file_animations_omta_scroll.html
without the patch, because we always have a new arrived animation after
waitForPaintsFlushed(). However, this test is still necessary to make
sure we really clear it.

In any case, without this patch, the visual result is intermittent because it
is still possible that there is no new animation arrived at the moment when
scrolling from active phase to before phase.

See Also: → 1552923
Assignee: nobody → boris.chiou

@scroll-timeline rule is dropped from the spec, so let's use new syntax.

This bug realized me that scroll-linked animations could be another source of power consumption where it looks like there's no need to keep vsync running. We probably need to a new machinery to sample scroll linked animations on the compositor as what we did on the main-thread.

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

This bug realized me that scroll-linked animations could be another source of power consumption where it looks like there's no need to keep vsync running. We probably need to a new machinery to sample scroll linked animations on the compositor as what we did on the main-thread.

This might be a little be tricky I guess, but it makes sense to me If there are only scroll-linked animations on the compositor. Would you mind filing a new bug blocks the meta (Bug 1676779)?

(In reply to Boris Chiou [:boris] from comment #4)

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

This bug realized me that scroll-linked animations could be another source of power consumption where it looks like there's no need to keep vsync running. We probably need to a new machinery to sample scroll linked animations on the compositor as what we did on the main-thread.

This might be a little be tricky I guess, but it makes sense to me If there are only scroll-linked animations on the compositor. Would you mind filing a new bug blocks the meta (Bug 1676779)?

Filed bug 1786448.

Make SampleAnimations() simpler and we may use this in the following patch.

Flags: needinfo?(boris.chiou)
Blocks: 1791884
Pushed by bchiou@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/e2974efe27e2
Drop @scroll-timeline from omta tests. r=hiro
https://hg.mozilla.org/integration/autoland/rev/6c2f62d6a8cd
Drop unused AnimationInfo::SetCompositorAnimations(). r=hiro
https://hg.mozilla.org/integration/autoland/rev/b8acc7fea941
Factor out the handle of storing animated value in SampleAnimations(). r=hiro
https://hg.mozilla.org/integration/autoland/rev/81bfa19dee83
Fix delay phase for scroll animations in the compositor thread. r=hiro
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: