This makes `Document::GetShell()` return `PresShell*` instead of `nsIPresShell`.
Additonally, "shell" is unclear ("docshell" vs. "presshell"). Therefore, this
also renames `Document::GetShell()` to `Document::GetPresShell()`.
Similarly, some other method names of `Document` are also renamed from
`*Shell*` to `*PresShell*`.
Differential Revision: https://phabricator.services.mozilla.com/D25338
--HG--
extra : moz-landing-system : lando
This makes `Document::GetShell()` return `PresShell*` instead of `nsIPresShell`.
Additonally, "shell" is unclear ("docshell" vs. "presshell"). Therefore, this
also renames `Document::GetShell()` to `Document::GetPresShell()`.
Similarly, some other method names of `Document` are also renamed from
`*Shell*` to `*PresShell*`.
Differential Revision: https://phabricator.services.mozilla.com/D25338
--HG--
extra : moz-landing-system : lando
For some content both transitions and animations are triggered simultaneously.
As a result of bug 1301305, if the set of animations includes animations that
affect geometry, then we ensure that any transform animations are run on the
main thread, rather than on the compositor.
However, we have observed some content where this synchronizing is not necessary
and produces unnecessary jank. In the particular cases we have observed,
the transitions and animations do not need to be synchronized so this patch
refines the approach from bug 1301305 to only synchronize within the set of CSS
transitions or the set of non-transition animations.
Differential Revision: https://phabricator.services.mozilla.com/D10328
--HG--
extra : moz-landing-system : lando
nsFrame::SchedulePaint() invokes InvalidateRenderingObservers, and
InvalidateRenderingObservers ends up posting change hints during we are
processing sequential tasks for animations, but we don't allow posting any
change hints while we are in the middle of restyling process.
Though the change hints posted by InvalidateRenderingObservers are not harmful
in this case since the change hints will be processed in a second post
traversal without problems. That's said, InvalidateRenderingObservers stuff
should be processed in display list based invalidation anyway (bug 1284053).
MozReview-Commit-ID: GKVRZ98lvEN
The approach here is to lazily check if we have such animations. This allows
animations to be modified after being added to the pending animation tracker
(but not after HasPlayPendingGeometricAnimations is called since we cache the
result at that point) and avoids poor performance when calling
RemovePlayPending.
MozReview-Commit-ID: LRLpCRnzvw
--HG--
extra : rebase_source : 59d2fea0458f833a97a3b32413930f9970c7eddb
extra : histedit_source : afbdb4148c21638160c3d2a3d57db71b07180862
This is in anticipation of adding Animation::SetTimeline(). Once we set the
timeline out of band, there's a chance that getting it could return null so
this patch makes the WebIDL and method name reflect that.
--HG--
extra : commitid : FSiwvrGRV1v
extra : rebase_source : 4c4004f58bbfd340642277b0a0b547a7de692dac
This is needed not only for supporting other kinds of timelines, but also for
when we come to implement SetTimeline(AnimationTimeline* aTimeline).
--HG--
extra : commitid : B836jCSbgNL
extra : rebase_source : 2592e66b2a9009f85ec0189ebecf5dba3c9bf8e0
This is not strictly necessary yet but we will want to implement methods
like GetAnimations() on the base class, AnimationTimeline, so we may as well do
that now rather than adding that code to DocumentTimeline and moving it later.
--HG--
extra : commitid : 7GU6Dr9lnPO
extra : rebase_source : d5e788874c72c422b57efbdb81404c79df6d505b
This patch also updates the method names on PendingAnimationTracker but leaves
a number of local variables which will be fixed in a subsequent patch.
--HG--
rename : dom/animation/PendingPlayerTracker.cpp => dom/animation/PendingAnimationTracker.cpp
rename : dom/animation/PendingPlayerTracker.h => dom/animation/PendingAnimationTracker.h
Masayuki Nakano
Dorel Luca
Brian Birtles
Sylvestre Ledru
Boris Zbarsky
Hiroyuki Ikezoe
Hiroyuki Ikezoe
Andrew McCreight