Different types of scrollers may need some special manipulation, e.g. we may
need to handle some special cases for `scroller(nearest)` in the
future (e.g. Bug 1765211). So making the hash key as a pair of scroller type
and scroller axis.
Differential Revision: https://phabricator.services.mozilla.com/D147773
Basically, animation-timeline could be
1. auto
2. none
3. <timeline-name>
We extend the <timeline-name> to cover both @scroll-timeline rule and
scroll-timeline-name property. We check @scroll-timeline rule first. If
it doesn't exist, we check scroll-timeline-name of the element itself,
the previous silbings, and their ancestors.
Differential Revision: https://phabricator.services.mozilla.com/D146358
There is a known issue: if we change overflow property of the
scroll-container, we may have to update the scroll-linked animations of
its descendants. This may be very tricky, so I filled Bug 1765211 for it.
Differential Revision: https://phabricator.services.mozilla.com/D143420
There is a known issue: if we change overflow property of the
scroll-container, we may have to update the scroll-linked animations of
its descendants. This may be very tricky, so I filled Bug 1765211 for it.
Differential Revision: https://phabricator.services.mozilla.com/D143420
We fallback to use main-thread animations if the timeline is inactive or we
cannot get scroll offsets or the scroll range from APZC on the compositor
thread.
Differential Revision: https://phabricator.services.mozilla.com/D141168
We don't send the animation to the compositor if it's scroll-timeline is
inactive (e.g. no layout frame or no scrollable frame).
Besdies, we also add a new struct, ScrollTimelineOptions, to represent
scroll timeline information in the IPC messages.
This patch handles the main thread side, and extract the information
from the transaction and store into AnimationStorageData.
We will sample ths scroll animations later in the patch series.
Differential Revision: https://phabricator.services.mozilla.com/D140548
We use a HashMap to keep the ScrollTimeline, and use scroll-direction as
the key, so a specific Element and a fixed scroll direction map to a specific
ScrollTimeline object. This means a maximum of one ScrollTimeline objects per
@scroll-timeline declaration.
If @scroll-timeline rule gets updated, we rebuild all the CSS
animations, and then re-check their ScrollTimeline objects. If there are
any unused old ScrollTimeline objects, their ref-counts will be zero
because only Animation object holds the strong reference,
so they will be removed from the associated ScrollTimelineSet and be
deleted automatically.
Note: We may have to update this once we support more descriptors in
@scroll-timeline. However, the syntax update is to obsolute @scroll-timeline,
so we don't have to address too many cases for now. This should be enough.
This is an internal optimization, and we can probably just rely on the existing
WPTs to test this without any memory leaks.
Differential Revision: https://phabricator.services.mozilla.com/D137236
Per spec, "auto" represents the scrolling element of the document.
However, the scrolling element might be changed, based on the layout, in
quirks mode. Besides, the content of the root scroll frame is the root
element, instead of the scrolling element (e.g. body element) in both
standard and quirks modes. So now we define a special type, Scroller, to
represent the source of scroll-timeline, and use its |mType| to decide
which scroll frame we would like to use. In addition, hope this change let
us easier to implement nearest scroller.
Note: for auto scroller, we register this ScrollTimeline to the root
element, in both modes. Once we expose ScrollTimeline interface to the
script, we can rely on the |mType| of Scroller to return the correct
source element, whether it is scrolling element or not.
Differential Revision: https://phabricator.services.mozilla.com/D131578
We hook the rule into cascade data, and so we can look it up by timeline
name. Now we only use StyleScrollDirection from @scroll-timeline rule.
`source` and `scroll-offsets` are skipped now and use the default values
instead because I'm pretty sure the syntax will be changed in Bug 1733260,
and `scroll-offsets` may be obsolete because the spec proposal intents to
make it be always 0% ~ 100%.
Also, add some reftests for the default `source` and `scroll-offsets`,
and different `orientation`s.
Besides, we disable at-scroll-timeline-start-end.html in Gecko because
we don't support start/end descriptors, and there are too many
intermittents in it.
Differential Revision: https://phabricator.services.mozilla.com/D126452
Based on https://github.com/w3c/csswg-drafts/pull/4842, we define
"has finite timeline", which is a timeline that's not monotonically increasing.
We need this to update start time and hold time for scroll-timeline, so
we play scroll-linked animations as we expected, e.g. GetLocalTime() returns
the correct time value from GetCurrentTimeAsDuration().
Known issue: we still have bugs when setting "animation-play-state:paused".
Will do that in Bug 1741255.
Differential Revision: https://phabricator.services.mozilla.com/D131168
This patch focus on the timing computation of animation effects. We have
to compute the correct progress based on the scroll offsets. Now we
simplify the implementation only from 0% to 100%. The test cases will be
added in the last patch once we hook the scroll timeline to the CSS
animation.
Differential Revision: https://phabricator.services.mozilla.com/D129101
The basic part of the infrastructure of scroll-linked animations. This is
designed based on scroll-linked animation generated by CSS. We will
implement the timing computation and hook the ScrollTimeline to the CSS
animations in the following patches.
All the tests are in the patch that hooks ScrollTimeline to CSS Animation.
Differential Revision: https://phabricator.services.mozilla.com/D129100
Boris Chiou
Noemi Erli