Bug 1245748 - Add a Move constructor to Keyframe; r=heycam
authorBrian Birtles <birtles@gmail.com>
Thu, 24 Mar 2016 10:39:29 +0900
changeset 290275 5081a75fbe8ccff1139853dbea6aeb92bd6fdc9d
parent 290274 5dbdbe3e4655a385663f25b7e16f85fbcf5f9207
child 290276 16620f50a9371ee739eaffb2524d1d53c71d684e
push id19656
push usergwagner@mozilla.com
push dateMon, 04 Apr 2016 13:43:23 +0000
treeherderb2g-inbound@e99061fde28a [default view] [failures only]
perfherder[talos] [build metrics] [platform microbench] (compared to previous push)
reviewersheycam
bugs1245748
milestone48.0a1
Bug 1245748 - Add a Move constructor to Keyframe; r=heycam I have confirmed that by adding this, we end up calling SwapElements() on the mPropertyValues member when we build up the nsTArray<Keyframe> result in GetKeyframeListFromPropertyIndexedKeyframe. Without this explicit move constructor (i.e. with only the default move constructor) the copy-constructor for mPropertyValues is called. MozReview-Commit-ID: 6IWkP97RFUr
dom/animation/KeyframeEffect.h
--- a/dom/animation/KeyframeEffect.h
+++ b/dom/animation/KeyframeEffect.h
@@ -77,16 +77,25 @@ struct PropertyValuePair
  * values, etc.
  *
  * When the target element or style context changes, however, we rebuild these
  * per-property arrays from the original list of keyframes objects. As a result,
  * these objects represent the master definition of the effect's values.
  */
 struct Keyframe
 {
+  Keyframe() = default;
+  Keyframe(Keyframe&& aOther)
+    : mOffset(aOther.mOffset)
+    , mComputedOffset(aOther.mComputedOffset)
+    , mTimingFunction(Move(aOther.mTimingFunction))
+    , mPropertyValues(Move(aOther.mPropertyValues))
+  {
+  }
+
   Maybe<double>                 mOffset;
   double                        mComputedOffset = 0.0;
   Maybe<ComputedTimingFunction> mTimingFunction; // Nothing() here means
                                                  // "linear"
   nsTArray<PropertyValuePair>   mPropertyValues;
 };
 
 struct AnimationPropertySegment