It's unused on mozilla-central, and Thunderbird can just use the canvas
frame as regular (X)HTML documents, so just use a canvas frame instead
of an nsRootBoxFrame for XUL as well.
nsRootBoxFrame was needed because of various XUL-specific things like
tooltips and so on lived there. But with the move away from XUL, that
functionality has been added to nsCanvasFrame already, behind a
principal check instead.
This also allows simplifying our background propagation setup, which was
only half-working for XUL documents (this bug is a consequence of that).
With this, most of the callers of nsCSSRendering::IsCanvasFrame can go.
They're only two of the frames that would return true for that that
actually paint backgrounds (nsCanvasFrame and nsRootBoxFrame), so the
codepaths in display list building and painting can just check
frame->IsCanvasFrame() instead.
The remaining caller to that function is
nsContainerFrame::SyncWindowProperties, and the change is also legit, in
the sense that the only thing SyncWindowProperties() really cares about
is propagating the max/min-width constraints from the root element's
style to the view/widget, and the only frame that would return true from
IsCanvasFrame and have a view is the viewport frame which is the root of
the frame tree.
Differential Revision: https://phabricator.services.mozilla.com/D90846
It's unused on mozilla-central, and Thunderbird can just use the canvas
frame as regular (X)HTML documents, so just use a canvas frame instead
of an nsRootBoxFrame for XUL as well.
nsRootBoxFrame was needed because of various XUL-specific things like
tooltips and so on lived there. But with the move away from XUL, that
functionality has been added to nsCanvasFrame already, behind a
principal check instead.
This also allows simplifying our background propagation setup, which was
only half-working for XUL documents (this bug is a consequence of that).
With this, most of the callers of nsCSSRendering::IsCanvasFrame can go.
They're only two of the frames that would return true for that that
actually paint backgrounds (nsCanvasFrame and nsRootBoxFrame), so the
codepaths in display list building and painting can just check
frame->IsCanvasFrame() instead.
The remaining caller to that function is
nsContainerFrame::SyncWindowProperties, and the change is also legit, in
the sense that the only thing SyncWindowProperties() really cares about
is propagating the max/min-width constraints from the root element's
style to the view/widget, and the only frame that would return true from
IsCanvasFrame and have a view is the viewport frame which is the root of
the frame tree.
Differential Revision: https://phabricator.services.mozilla.com/D90846
Basically, we need to detect a case if there is only scroll animations
which are not sampled because it goes back to before phase. If this
happens, we set ScrollToDelay to |mReason| in the returned value.
Without this patch, the visual result is intermittent because it
is possible that there are new animations arrived at the moment when
scrolling from active phase to before phase.
We don't have a test for after phase because we don't support end delay
for scroll animations now. However, although we set the adjusted fill, we may
still need this in the future so let's keep the check of after phase for now.
Differential Revision: https://phabricator.services.mozilla.com/D155108
`sTiming` is a hack and I believe animation-delay,
animation-iteration-count, animation-direction, and animation-fill-mode
should be meaningful for scroll-linked animations. (I will add the
tentative wpt in Bug 1775327.)
So we need to introduce a normalized timing when resolving the specified
timing.
Also, this patch makes the bug of printing scroll animations detectable.
No behavior is changed and I'd like to remove the magic values and do
normalization in Bug 1775327.
Note: Based on https://github.com/w3c/csswg-drafts/issues/4862 and
web-animations-2, we will introudce CSSNumberish for duration, current
time, and delay. That is, we will accept percentage for
animation-duration, animation-delay. However, Gecko doesn't support
CSSNumberish for those values, so we'd like to normalize these time values
in Bug 1775327. This patch is the 1st step: split the normalized
timing from the specified timing, and use it when resolving the
timing, for progress-based timeline.
Differential Revision: https://phabricator.services.mozilla.com/D149683
None of the consumer need to mutate styles, and this saves some ugly
const_casting on the next patch.
Doesn't change behavior.
Differential Revision: https://phabricator.services.mozilla.com/D147555
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
For simplicity purposes, we don't consider OMTA for now. OMTA support
for scoll-timeline will be done in Bug 1737180.
However, in this patch, we would like to address:
if the geometic animations use scroll-timeline, we don't have to let it
affect the transform animations on the same animation target:
1. If we don't do scrolling, its geometric properties don't change, so no
effect on transform-like properties.
2. If we do scrolling, we may un-throttle the transform animations by
other ways, e.g. Keyframe::CanThrottle(). So we don't need to worry
about this.
Note: tests are in the next patch.
Differential Revision: https://phabricator.services.mozilla.com/D129103
This will make implementing the new behavior behind a pref
really straight-forward, and is generally nicer.
Depends on D121858
Differential Revision: https://phabricator.services.mozilla.com/D121705
It's unused on mozilla-central, and Thunderbird can just use the canvas
frame as regular (X)HTML documents, so just use a canvas frame instead
of an nsRootBoxFrame for XUL as well.
nsRootBoxFrame was needed because of various XUL-specific things like
tooltips and so on lived there. But with the move away from XUL, that
functionality has been added to nsCanvasFrame already, behind a
principal check instead.
This also allows simplifying our background propagation setup, which was
only half-working for XUL documents (this bug is a consequence of that).
With this, most of the callers of nsCSSRendering::IsCanvasFrame can go.
They're only two of the frames that would return true for that that
actually paint backgrounds (nsCanvasFrame and nsRootBoxFrame), so the
codepaths in display list building and painting can just check
frame->IsCanvasFrame() instead.
The remaining caller to that function is
nsContainerFrame::SyncWindowProperties, and the change is also legit, in
the sense that the only thing SyncWindowProperties() really cares about
is propagating the max/min-width constraints from the root element's
style to the view/widget, and the only frame that would return true from
IsCanvasFrame and have a view is the viewport frame which is the root of
the frame tree.
Differential Revision: https://phabricator.services.mozilla.com/D90846
It probably did something more useful in the past, but right now it's
only used to avoid throttling some overflow-causing animations.
It returns 0 everywhere except on Android (for some reason?), but in any
case it doesn't seem this would need to be a LookAndFeel integer, it
could just be a regular pref that we turn on for tests.
However the tests pass with this patch locally, so for now I'm not
adding a pref to replace it.
Differential Revision: https://phabricator.services.mozilla.com/D120871
So that now EffectCompositor::HasAnimationsForCompositor doesn't return true
for such cases, thus we will not accidentally try to generate
nsDisplayBackgroundColor display item for such animations (bug 1699890#c21)
and we will not generate nsChangeHint_RepaintFrame (bug 1701547) either.
Differential Revision: https://phabricator.services.mozilla.com/D115774
So that now EffectCompositor::HasAnimationsForCompositor doesn't return true
for such cases, thus we will not accidentally try to generate
nsDisplayBackgroundColor display item for such animations (bug 1699890#c21)
and we will not generate nsChangeHint_RepaintFrame (bug 1701547) either.
Differential Revision: https://phabricator.services.mozilla.com/D115774
This makes the naming more consistent with other functions called
Insert and/or Update. Also, it removes the ambiguity whether
Put expects that an entry already exists or not, in particular because
it differed from nsTHashtable::PutEntry in that regard.
Differential Revision: https://phabricator.services.mozilla.com/D105473
This lifts a bunch of string conversions higher up the stack, but allows
us to make the servo code use utf-8 unconditionally, and seemed faster
in my benchmarking (see comment 0).
It should also make a bunch of attribute setters faster too (like
setting .cssText), now that we use UTF8String for them (we couldn't
because we couldn't specify different string types for the getter and
setters).
Differential Revision: https://phabricator.services.mozilla.com/D99590
Changes to nsIScrollableFrame.h cause the world to rebuild which I find annoying.
This removes the inclusion into Element.h which is responsible for the
world-rebuilding and is relatively easy to eliminate. A bunch of usages of
nsIScrollableFrame get moved from .h files into .cpp files and I include the
header into .cpp files as needed.
Differential Revision: https://phabricator.services.mozilla.com/D90735
The machinery to report janked animations is;
1) Store the partial pre-rendered animation id and the Animation object in a
hashtable in LayerManager
2) Store the animation id in the Animation object as well
3) When we detect jank, we send the animation id to the main-thread via an IPC
call
4) Find the Animation object with the id in the hashtable and update the
Animaiton
5) Whenever the partial pre-rendered Animation stop running on the compositor
i.e. the Animation finished normally, the Animation's target element is
changed, etc. etc., remove the Animation from the hashtable
Depends on D75731
Differential Revision: https://phabricator.services.mozilla.com/D75732
The machinery to report janked animations is;
1) Store the partial pre-rendered animation id and the Animation object in a
hashtable in LayerManager
2) Store the animation id in the Animation object as well
3) When we detect jank, we send the animation id to the main-thread via an IPC
call
4) Find the Animation object with the id in the hashtable and update the
Animaiton
5) Whenever the partial pre-rendered Animation stop running on the compositor
i.e. the Animation finished normally, the Animation's target element is
changed, etc. etc., remove the Animation from the hashtable
Differential Revision: https://phabricator.services.mozilla.com/D75732
When transitioning visibility and opacity at the same time, we create
two effects, one animating opacity, and one visibility.
We're incorrectly throttling the visibility animation due to opacity,
because _that_ effect is not animating opacity, but the other one is and
thus doesn't get throttled.
Use HasAnimationOfOpacity() to check for this case. This is slightly
sketchy, because the first time we get through there we may not even
have started the opacity animation yet. However it kinda works, because
the fact that there's a (non-throttled, because of the
aEffect.HasOpacityChange()) opacity animation means that we'll tick both
of them, and unthrottle them next frame.
This seems better than the alternative which is never throttling
animations in opacity: 0 roots.
Differential Revision: https://phabricator.services.mozilla.com/D76405
This also requires changing the EffectCompositor to allow animations in print
and print preview, and setting up a document timeline for the cloned document
Differential Revision: https://phabricator.services.mozilla.com/D69069
