Before this patch, there is a race condition that the refresh driver updates
the most recent refresh time but animations corresponding to the refresh driver
don't update their internal state, that causes the inconsistency that such
animations are regarded as finished on the most recent time whereas their
internal states represent the animations are still in active. This is the one
of the cause of bug 1466010, i.e. the display item corresponding to the
animation is going to be rebuilt without calling MarkNeedsDisplayItemRebuild.
MozReview-Commit-ID: 9adzDV9E3ka
These epoch times were introduced for beforepaint event in bug 569520, and
haven't used since we dropped mozRequestAnimationFrame in bug 909154.
MozReview-Commit-ID: CGOGeH0rrdi
mMostRecentRefresh is changed not only in Tick() but also in
EnsureTimerStarted(). In the case where it happens in Tick() refresh observers
can know it through WillRefresh(), but there is no way in the case of
EnsureTimerStarted(). This patch introduces a new abstract class to be notified
when mMostRecentRefresh was changed in EnsureTimerStarted() so that animations
can use the *real* most recent refresh time until the next tick happens.
The reason why we have another observer array in parallel with existing array
(mObservers) is that the refresh driver should stop the timer if there is no
normal observes but there are still any timer adjustment observes.
MozReview-Commit-ID: FaDcl5GrvI3
The nsCSSFrameConstructor bits are now handled in PresShell::Destroy along with
the other refresh driver observers.
I cleaned up the nsRefreshDriver methods because they were using infallible
append anyway, and that simplified the logic.
MozReview-Commit-ID: 1eDUUXjUUS9
So that we can now ensure nsRefreshDriver ticks (i.e. nsRefreshDriver doesn't
stop its timer) for all queued events.
Before this patch, dispatching CSS animation/transition events relied on the
fact that DocumentTimeline observes nsRefreshDriver. For this fact,
animationcancel or transitioncancel event did not dispatch properly in some
cases, i.e. the case where the animation was dropped from the DocumentTimeline.
MozReview-Commit-ID: 7JYro0MY2U2
We just need information whether there is still an observer or not in most
cases. The only case we need to know the count is in an assertion in the
dtor of nsRefreshDriver. In the dtor we are checking there remains no
observers other than early runners.
Note that the order in HasObserver() was adjusted to reflect that we check
boolean flag first (mViewManagerFlushIsPending) and subsequently check observer
which is likey happen to. mFrameRequestCallbackDocs should have checked prior
to mResizeEventFlushObservers though.
MozReview-Commit-ID: E1qplusqw1Y
So that we can now ensure nsRefreshDriver ticks (i.e. nsRefreshDriver doesn't
stop its timer) for all queued events.
Before this patch, dispatching CSS animation/transition events relied on the
fact that DocumentTimeline observes nsRefreshDriver. For this fact,
animationcancel or transitioncancel event did not dispatch properly in some
cases, i.e. the case where the animation was dropped from the DocumentTimeline.
MozReview-Commit-ID: 7JYro0MY2U2
We just need information whether there is still an observer or not in most
cases. The only case we need to know the count is in an assertion in the
dtor of nsRefreshDriver. In the dtor we are checking there remains no
observers other than early runners.
Note that the order in HasObserver() was adjusted to reflect that we check
boolean flag first (mViewManagerFlushIsPending) and subsequently check observer
which is likey happen to. mFrameRequestCallbackDocs should have checked prior
to mResizeEventFlushObservers though.
MozReview-Commit-ID: E1qplusqw1Y
We don't need to collect whole descendants documents.
This patch intentionally leaves animation events handling which is another
caller of CollectDocuments in nsRefreshDriver since the animation part will
be fixed in a different way in bug 1415780.
MozReview-Commit-ID: INAJm1NHLuI
This patch was generated automatically by the "modeline.py" script, available
here: https://github.com/amccreight/moz-source-tools/blob/master/modeline.py
For every file that is modified in this patch, the changes are as follows:
(1) The patch changes the file to use the exact C++ mode lines from the
Mozilla coding style guide, available here:
https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Coding_Style#Mode_Line
(2) The patch deletes any blank lines between the mode line & the MPL
boilerplate comment.
(3) If the file previously had the mode lines and MPL boilerplate in a
single contiguous C++ comment, then the patch splits them into
separate C++ comments, to match the boilerplate in the coding style.
MozReview-Commit-ID: EuRsDue63tK
Currently the Gecko Profiler defines a moderate amount of stuff when
MOZ_GECKO_PROFILER is undefined. It also #includes various headers, including
JS ones. This is making it difficult to separate Gecko's media stack for
inclusion in Servo.
This patch greatly simplifies how things are exposed. The starting point is:
- GeckoProfiler.h can be #included unconditionally;
- everything else from the profiler must be guarded by MOZ_GECKO_PROFILER.
In practice this introduces way too many #ifdefs, so the patch loosens it by
adding no-op macros for a number of the most common operations.
The net result is that #ifdefs and macros are used a bit more, but almost
nothing is exposed in non-MOZ_GECKO_PROFILER builds (including
ProfilerMarkerPayload.h and GeckoProfiler.h), and understanding what is exposed
is much simpler than before.
Note also that in BHR, ThreadStackHelper is now entirely absent in
non-MOZ_GECKO_PROFILER builds.
This ensures that if the scroll event triggers style changes, they are
reflected on the same paint.
This is accomplished by having the refresh driver fire scroll events as
an explicit step after FlushType::Style observers and rAF callbacks, and
before the actual style flush.
MozReview-Commit-ID: 4kgauD5SgVo
Bug 731974 added this code to get more accurate timer callbacks back when the refresh driver was based on timers. It shouldn't be needed anymore now that the refresh driver is based on vsync.
We added this so that MozAfterPaint events would be delivered to hidden documents as part of bug 539356, but I don't remember what needed it.
It doesn't appear to be necessary for any tests any more, so let's just get rid of it
MozReview-Commit-ID: HcmIjstZyLQ
