%l seems to be for hour in 12hr clock (i.e. 1-12), but we're applying it to a filesize.
%d seems more appropriate in order to display the actual raw filesize.
MozReview-Commit-ID: AKTpYndm81o
--HG--
extra : rebase_source : 4107bd4ebbe6169ecd3823b2613099bb73ae81a1
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
Note that in this patch, the mSyncWithGeometricAnimations member is never set
to true since no one calls NotifyGeometricAnimationsStartingThisFrame yet.
MozReview-Commit-ID: GSTQmfkSdoy
--HG--
extra : rebase_source : 1304cdf678095f2eeaa32588b92c0531e8c64fcd
extra : histedit_source : bc25fc10a2451121a2b9fec247db3f92965e9b5b
This should be easier to read and provide us a convenient place to check for
other cases where we need to synchronize with the main thread (such as the
change introduced in this bug where we synchronize with other animations
started at the same time).
MozReview-Commit-ID: 8iuA7P4ycwM
--HG--
extra : rebase_source : 60a706d51897a0522794cd140734ad7158f4ccd6
extra : histedit_source : cbd0849fcb9077afaf3d2cd3f168201ddb2bf7a4
This patch adds a new performance warning type for the case when we start
a transform animation at the same time as an animation that includes a
geometric property. In that case we run the transform animation on the main
thread so that it is synchronized with the geometric animation (which we can
only run on the main thread).
This differs from CompositorAnimationWarningTransformWithGeometricProperties
in that this applies across different elements whilst the existing warning
only covers the case when the same animation animates both transform and
geometric properties.
MozReview-Commit-ID: EcOMo4VDAYY
--HG--
extra : rebase_source : b4bbc3e4ffa69d0d741fe6d67aba0349b9325b3e
extra : histedit_source : 9fd1b33e8776e270241cde40f1905e74fdfcb630
In subsequent patches in this bug we will change the heuristics for determining
which transform animations run on the compositor. As a result some assumptions
in DevTools tests about which animations run on the compositor will change.
Since the heuristics for transform animations are more complex than opacity
animations, in this patch we just switch those animations to use opacity
instead (and add an animation rule that clearly marks that it expects all its
properties to run on the compositor).
MozReview-Commit-ID: FfDUAzKJRCz
--HG--
extra : rebase_source : 6e0a30658d35fa236f9d8bfb343cb4355b4ce0e5
extra : histedit_source : 700cc9b3352caf06008224f7e5651ba7f63890b1
If margin or padding is being animated then we should synchronize with transform
animations.
Originally I included the border-*-width properties in this set. However
I removed them because:
1. Generally animations of border-width are more subtle and it won't be
noticeable if they are not synchronized with transform animations.
2. If authors animate the border shorthand (e.g. border: 1px blue -> 1px black)
we will end up interpolating each of the longhands (including the widths
despite there being no change) and yet such an animation does not really need
to be synchronized with transform animations. Until we add code to workaround
that it seems best to ignore border properties.
I have verified that the tests added in this patch fail without the code changes
in this patch.
MozReview-Commit-ID: AJiDAvTpFuN
--HG--
extra : rebase_source : 58462ab48acc0b1298915d0d3572915b6973ac82
extra : histedit_source : d293cfc68ff59483b4f9543a7a63b140d627a4fa
We would like to use this method in the next patch.
MozReview-Commit-ID: CSdwlVInyds
--HG--
extra : rebase_source : 5e9af4f0ffacaaf08ecee4e6018bed1ee4a74047
extra : histedit_source : b73144f07097982236038c3efb391f6b7d00e5ed
Currently we have:
assert_animation_property_state_equals
assert_animation_property_state_on_compositor
and it's not clear what the difference is. This patch renames the latter to make
it clear it is testing that all properties are running on the compositor.
MozReview-Commit-ID: 3PRm8fse9UI
--HG--
extra : rebase_source : ff89d0e6a5f9e59990ead431200726b492f71e81
extra : histedit_source : c003d1806baf2a97252a734506ac2934e01a4839
Currently these tests are hard to read because the test data is separated from
the test function so it's not clear what each of the fields mean or how to use
it. This patch just brings the test data and test functions alongside
one-another so they are easier to read.
MozReview-Commit-ID: EzFLDG4YiXh
--HG--
extra : rebase_source : 9a6745e908e1794dd92c8d264acc6c61923f4242
extra : histedit_source : 1961454b749bc9cf74d5ae9eef4ac9e4d827179c
Cameron McCormack
Phil Ringnalda
Jan de Mooij
Luke Wagner
Nathan Froyd
Jon Coppeard
Kan-Ru Chen
Valentin Gosu
Robert Strong
Andrea Marchesini
Aaron Klotz
Sebastian Hengst
Andrzej Hunt
Brian Birtles
Benjamin Bouvier
JOrg K
Carsten "Tomcat" Book
Boris Zbarsky
Jeff Gilbert
John Lin
Emanuel Hoogeveen
Wei-Cheng Pan
Andreas Pehrson
vincentliu
Mike Shal
Ryan Hunt