When we receive animations on the compositor, we assert that either they're not
playing, or they have a resolved start and origin time.
However, on the main thread we determine if an animation is playing by checking
if it has a timeline, if it's in the correct state, and if it has a non-zero
playback rate.
The problem with this check is that if an animation has a timeline but it is
inactive, that is, its current time is null, we will not be able to get
a resolved origin time -- yet we will still report that is is playing.
This patch fixes this mismatch by treating animations with an inactive timeline
as "not playing".
The IsPlaying() method is used a number of call sites but it appears that they
all would expect an animation with an inactive timeline to be considered "not
playing". Furthermore, this makes IsPlaying() consistent with the check we do
for an active timeline in other functions such as Animation::Tick(),
TriggerNow(), SilentlySetCurrentTime(), UpdateFinishedState(),
and IsPossibleOrphanedPendingAnimation().
MozReview-Commit-ID: BQOBpHHFMoD
--HG--
extra : rebase_source : e84a50a16a61d48553610cb7ea0863f09ba86c60
moz.configure files are covered by flake8. Earlier today, my push
in bug 1411784 didn't run flake8 and a flake8 failure was uncovered
by a subsequent push that touched a .py file.
MozReview-Commit-ID: HzL8wOQaqRC
--HG--
extra : rebase_source : 1091be0bab2f2a23cdbaaa3d6b52072693f5f356
Connection handling code wasn't handling errors from receive()
properly. Attempting to unwrap on an Err was causing a panic.
MozReview-Commit-ID: GURe3FHPbjT
--HG--
extra : rebase_source : 664bf389020feb4a12f43422351c20ab7e804e30
The timestamps are automatically truncated when they're stored in
prefs, which is fine because we don't need millisecond precision.
However, the truncation raises a warning, so we need to explicitly
floor the values.
MozReview-Commit-ID: BRflL6s0b1
--HG--
extra : rebase_source : 6724a1ad05cb8aee4ab8c666545784960c23a0f3
This also introduces C{XX}_LDFLAGS variables which contain cflags that
are meant to be passed to the linker, and adds them to various linker
command lines in place of CFLAGS.
MozReview-Commit-ID: GyKlD9nMqrt
This commit establishes a separate variable to add PROFILE_GEN and PROFILE_USE
CFLAGS to compile and link command lines. Currently the make backend
orchestrates the pgo build steps and is the only thing aware of whether
we're in the profile generate or profile use stage. The flags are separated
here to allow other flags to be moved to mozbuild, but this will not yet
sufficient to perform a PGO build independent of the make backend.
MozReview-Commit-ID: IX30l2MvvNc
While we're here, provide a reference to unique_list as defined in
moz.configure when executing config.data to avoid its redefinition
in m4.
MozReview-Commit-ID: AI6XhoYR0Ye
When we move to a shell aware split for AC_SUBST_LIST it will become an error
to emit an unquoted make variable reference. Currently this happens to only
occur during artifact builds when setting cflags related variables that aren't
needed there anyway, so here we skip settting those variables when a compile
environment isn't present.
MozReview-Commit-ID: EnHu48yyZ1C
