2017-01-25 05:51:30 +03:00
|
|
|
/* -*- Mode: C++; tab-width: 8; indent-tabs-mode: nil; c-basic-offset: 2 -*- */
|
|
|
|
/* vim: set ts=8 sts=2 et sw=2 tw=80: */
|
|
|
|
/* This Source Code Form is subject to the terms of the Mozilla Public
|
|
|
|
* License, v. 2.0. If a copy of the MPL was not distributed with this
|
|
|
|
* file, You can obtain one at http://mozilla.org/MPL/2.0/. */
|
|
|
|
|
|
|
|
#ifndef mozilla_layers_AnimationHelper_h
|
|
|
|
#define mozilla_layers_AnimationHelper_h
|
|
|
|
|
2018-04-24 03:27:54 +03:00
|
|
|
#include "mozilla/dom/Nullable.h"
|
2019-03-22 21:28:42 +03:00
|
|
|
#include "mozilla/ComputedTimingFunction.h" // for ComputedTimingFunction
|
|
|
|
#include "mozilla/layers/LayersMessages.h" // for TransformData, etc
|
|
|
|
#include "mozilla/webrender/WebRenderTypes.h" // for RenderRoot
|
|
|
|
#include "mozilla/TimeStamp.h" // for TimeStamp
|
2018-04-24 03:27:53 +03:00
|
|
|
#include "mozilla/TimingParams.h"
|
2019-04-11 15:37:06 +03:00
|
|
|
#include "mozilla/Variant.h"
|
2018-04-24 03:27:54 +03:00
|
|
|
#include "X11UndefineNone.h"
|
2017-01-25 05:51:30 +03:00
|
|
|
|
|
|
|
namespace mozilla {
|
2017-09-21 12:01:48 +03:00
|
|
|
struct AnimationValue;
|
Bug 1425837 - Part 3: Don't store AnimationArray (a.k.a. AnimationInfo::mAnimations) on the compositor thread. r=birtles
The original implementation about "setting animations" is a little bit hard
to read. In `SetAnimations()`, we create a new intermediate data,
`AnimData`, and we mutate the original animations. And then iterate this
mutated animations & intermediate data for sampling. In this bug, we are
planning to group the AnimData as a useful data structure for supporting
multiple properties transform-like animations, so it seems the structure
of original animations may be hard to use after that. Therefore,
we decide to do some reworks on this:
First, we do renames,
1. InfalliableTArray to nsTArray. (They are the same.)
2. AnimData to PropertyAnimation.
3. SetAnimations() to ExtractAnimations(), which returns
nsTArray<PropertyAnimationGroup>. Each entry in the array is for one
property. In this patch, there is only one entry. We will extend this
to multiple entries in the next patch.
And then rework `ExtractAnimations()`, which stores all the necessary data
in `PropertyAnimationGroup`. For WR, we store this in
`CompositorAnimationStorage`. For non-WR, we store it in `AnimationInfo`.
So we can just use this organized data structure for supporting multiple
properties animations. (See the next patch.)
Depends on D22563
Differential Revision: https://phabricator.services.mozilla.com/D23062
--HG--
extra : moz-landing-system : lando
2019-03-18 21:04:48 +03:00
|
|
|
|
|
|
|
namespace dom {
|
|
|
|
enum class CompositeOperation : uint8_t;
|
|
|
|
enum class IterationCompositeOperation : uint8_t;
|
|
|
|
}; // namespace dom
|
|
|
|
|
2017-01-25 05:51:30 +03:00
|
|
|
namespace layers {
|
|
|
|
class Animation;
|
|
|
|
|
Bug 1425837 - Part 3: Don't store AnimationArray (a.k.a. AnimationInfo::mAnimations) on the compositor thread. r=birtles
The original implementation about "setting animations" is a little bit hard
to read. In `SetAnimations()`, we create a new intermediate data,
`AnimData`, and we mutate the original animations. And then iterate this
mutated animations & intermediate data for sampling. In this bug, we are
planning to group the AnimData as a useful data structure for supporting
multiple properties transform-like animations, so it seems the structure
of original animations may be hard to use after that. Therefore,
we decide to do some reworks on this:
First, we do renames,
1. InfalliableTArray to nsTArray. (They are the same.)
2. AnimData to PropertyAnimation.
3. SetAnimations() to ExtractAnimations(), which returns
nsTArray<PropertyAnimationGroup>. Each entry in the array is for one
property. In this patch, there is only one entry. We will extend this
to multiple entries in the next patch.
And then rework `ExtractAnimations()`, which stores all the necessary data
in `PropertyAnimationGroup`. For WR, we store this in
`CompositorAnimationStorage`. For non-WR, we store it in `AnimationInfo`.
So we can just use this organized data structure for supporting multiple
properties animations. (See the next patch.)
Depends on D22563
Differential Revision: https://phabricator.services.mozilla.com/D23062
--HG--
extra : moz-landing-system : lando
2019-03-18 21:04:48 +03:00
|
|
|
typedef nsTArray<layers::Animation> AnimationArray;
|
|
|
|
|
|
|
|
struct PropertyAnimation {
|
|
|
|
struct SegmentData {
|
|
|
|
RefPtr<RawServoAnimationValue> mStartValue;
|
|
|
|
RefPtr<RawServoAnimationValue> mEndValue;
|
|
|
|
Maybe<mozilla::ComputedTimingFunction> mFunction;
|
|
|
|
float mStartPortion;
|
|
|
|
float mEndPortion;
|
|
|
|
dom::CompositeOperation mStartComposite;
|
|
|
|
dom::CompositeOperation mEndComposite;
|
|
|
|
};
|
|
|
|
nsTArray<SegmentData> mSegments;
|
2018-04-24 03:27:53 +03:00
|
|
|
TimingParams mTiming;
|
Bug 1425837 - Part 3: Don't store AnimationArray (a.k.a. AnimationInfo::mAnimations) on the compositor thread. r=birtles
The original implementation about "setting animations" is a little bit hard
to read. In `SetAnimations()`, we create a new intermediate data,
`AnimData`, and we mutate the original animations. And then iterate this
mutated animations & intermediate data for sampling. In this bug, we are
planning to group the AnimData as a useful data structure for supporting
multiple properties transform-like animations, so it seems the structure
of original animations may be hard to use after that. Therefore,
we decide to do some reworks on this:
First, we do renames,
1. InfalliableTArray to nsTArray. (They are the same.)
2. AnimData to PropertyAnimation.
3. SetAnimations() to ExtractAnimations(), which returns
nsTArray<PropertyAnimationGroup>. Each entry in the array is for one
property. In this patch, there is only one entry. We will extend this
to multiple entries in the next patch.
And then rework `ExtractAnimations()`, which stores all the necessary data
in `PropertyAnimationGroup`. For WR, we store this in
`CompositorAnimationStorage`. For non-WR, we store it in `AnimationInfo`.
So we can just use this organized data structure for supporting multiple
properties animations. (See the next patch.)
Depends on D22563
Differential Revision: https://phabricator.services.mozilla.com/D23062
--HG--
extra : moz-landing-system : lando
2019-03-18 21:04:48 +03:00
|
|
|
|
2018-04-24 03:27:54 +03:00
|
|
|
// These two variables correspond to the variables of the same name in
|
|
|
|
// KeyframeEffectReadOnly and are used for the same purpose: to skip composing
|
|
|
|
// animations whose progress has not changed.
|
|
|
|
dom::Nullable<double> mProgressOnLastCompose;
|
|
|
|
uint64_t mCurrentIterationOnLastCompose = 0;
|
|
|
|
// These two variables are used for a similar optimization above but are
|
|
|
|
// applied to the timing function in each keyframe.
|
|
|
|
uint32_t mSegmentIndexOnLastCompose = 0;
|
|
|
|
dom::Nullable<double> mPortionInSegmentOnLastCompose;
|
Bug 1425837 - Part 3: Don't store AnimationArray (a.k.a. AnimationInfo::mAnimations) on the compositor thread. r=birtles
The original implementation about "setting animations" is a little bit hard
to read. In `SetAnimations()`, we create a new intermediate data,
`AnimData`, and we mutate the original animations. And then iterate this
mutated animations & intermediate data for sampling. In this bug, we are
planning to group the AnimData as a useful data structure for supporting
multiple properties transform-like animations, so it seems the structure
of original animations may be hard to use after that. Therefore,
we decide to do some reworks on this:
First, we do renames,
1. InfalliableTArray to nsTArray. (They are the same.)
2. AnimData to PropertyAnimation.
3. SetAnimations() to ExtractAnimations(), which returns
nsTArray<PropertyAnimationGroup>. Each entry in the array is for one
property. In this patch, there is only one entry. We will extend this
to multiple entries in the next patch.
And then rework `ExtractAnimations()`, which stores all the necessary data
in `PropertyAnimationGroup`. For WR, we store this in
`CompositorAnimationStorage`. For non-WR, we store it in `AnimationInfo`.
So we can just use this organized data structure for supporting multiple
properties animations. (See the next patch.)
Depends on D22563
Differential Revision: https://phabricator.services.mozilla.com/D23062
--HG--
extra : moz-landing-system : lando
2019-03-18 21:04:48 +03:00
|
|
|
|
|
|
|
TimeStamp mOriginTime;
|
2019-03-25 22:29:46 +03:00
|
|
|
Maybe<TimeDuration> mStartTime;
|
Bug 1425837 - Part 3: Don't store AnimationArray (a.k.a. AnimationInfo::mAnimations) on the compositor thread. r=birtles
The original implementation about "setting animations" is a little bit hard
to read. In `SetAnimations()`, we create a new intermediate data,
`AnimData`, and we mutate the original animations. And then iterate this
mutated animations & intermediate data for sampling. In this bug, we are
planning to group the AnimData as a useful data structure for supporting
multiple properties transform-like animations, so it seems the structure
of original animations may be hard to use after that. Therefore,
we decide to do some reworks on this:
First, we do renames,
1. InfalliableTArray to nsTArray. (They are the same.)
2. AnimData to PropertyAnimation.
3. SetAnimations() to ExtractAnimations(), which returns
nsTArray<PropertyAnimationGroup>. Each entry in the array is for one
property. In this patch, there is only one entry. We will extend this
to multiple entries in the next patch.
And then rework `ExtractAnimations()`, which stores all the necessary data
in `PropertyAnimationGroup`. For WR, we store this in
`CompositorAnimationStorage`. For non-WR, we store it in `AnimationInfo`.
So we can just use this organized data structure for supporting multiple
properties animations. (See the next patch.)
Depends on D22563
Differential Revision: https://phabricator.services.mozilla.com/D23062
--HG--
extra : moz-landing-system : lando
2019-03-18 21:04:48 +03:00
|
|
|
TimeDuration mHoldTime;
|
|
|
|
float mPlaybackRate;
|
|
|
|
dom::IterationCompositeOperation mIterationComposite;
|
|
|
|
bool mIsNotPlaying;
|
|
|
|
};
|
|
|
|
|
|
|
|
struct PropertyAnimationGroup {
|
|
|
|
nsCSSPropertyID mProperty;
|
2019-03-29 22:54:14 +03:00
|
|
|
Maybe<TransformData> mAnimationData;
|
Bug 1425837 - Part 3: Don't store AnimationArray (a.k.a. AnimationInfo::mAnimations) on the compositor thread. r=birtles
The original implementation about "setting animations" is a little bit hard
to read. In `SetAnimations()`, we create a new intermediate data,
`AnimData`, and we mutate the original animations. And then iterate this
mutated animations & intermediate data for sampling. In this bug, we are
planning to group the AnimData as a useful data structure for supporting
multiple properties transform-like animations, so it seems the structure
of original animations may be hard to use after that. Therefore,
we decide to do some reworks on this:
First, we do renames,
1. InfalliableTArray to nsTArray. (They are the same.)
2. AnimData to PropertyAnimation.
3. SetAnimations() to ExtractAnimations(), which returns
nsTArray<PropertyAnimationGroup>. Each entry in the array is for one
property. In this patch, there is only one entry. We will extend this
to multiple entries in the next patch.
And then rework `ExtractAnimations()`, which stores all the necessary data
in `PropertyAnimationGroup`. For WR, we store this in
`CompositorAnimationStorage`. For non-WR, we store it in `AnimationInfo`.
So we can just use this organized data structure for supporting multiple
properties animations. (See the next patch.)
Depends on D22563
Differential Revision: https://phabricator.services.mozilla.com/D23062
--HG--
extra : moz-landing-system : lando
2019-03-18 21:04:48 +03:00
|
|
|
|
|
|
|
nsTArray<PropertyAnimation> mAnimations;
|
|
|
|
RefPtr<RawServoAnimationValue> mBaseStyle;
|
|
|
|
|
|
|
|
bool IsEmpty() const { return mAnimations.IsEmpty(); }
|
|
|
|
void Clear() {
|
|
|
|
mAnimations.Clear();
|
|
|
|
mBaseStyle = nullptr;
|
|
|
|
}
|
2017-01-25 05:51:30 +03:00
|
|
|
};
|
|
|
|
|
2017-02-10 01:30:11 +03:00
|
|
|
struct AnimationTransform {
|
|
|
|
/*
|
|
|
|
* This transform is calculated from sampleanimation in device pixel
|
|
|
|
* and used by compositor.
|
|
|
|
*/
|
|
|
|
gfx::Matrix4x4 mTransformInDevSpace;
|
|
|
|
/*
|
|
|
|
* This transform is calculated from frame and used by getOMTAStyle()
|
|
|
|
* for OMTA testing.
|
|
|
|
*/
|
|
|
|
gfx::Matrix4x4 mFrameTransform;
|
|
|
|
TransformData mData;
|
|
|
|
};
|
|
|
|
|
2019-04-11 15:36:51 +03:00
|
|
|
struct AnimatedValue final {
|
2019-04-11 15:37:06 +03:00
|
|
|
typedef Variant<AnimationTransform, float, nscolor> AnimatedValueType;
|
2017-02-10 01:30:11 +03:00
|
|
|
|
2019-04-11 15:37:06 +03:00
|
|
|
const AnimatedValueType& Value() const { return mValue; }
|
|
|
|
const AnimationTransform& Transform() const {
|
|
|
|
return mValue.as<AnimationTransform>();
|
|
|
|
}
|
|
|
|
const float& Opacity() const { return mValue.as<float>(); }
|
|
|
|
const nscolor& Color() const { return mValue.as<nscolor>(); }
|
|
|
|
template <typename T>
|
|
|
|
bool Is() const {
|
|
|
|
return mValue.is<T>();
|
|
|
|
}
|
2017-02-10 01:30:11 +03:00
|
|
|
|
|
|
|
AnimatedValue(gfx::Matrix4x4&& aTransformInDevSpace,
|
|
|
|
gfx::Matrix4x4&& aFrameTransform, const TransformData& aData)
|
2019-04-11 15:37:06 +03:00
|
|
|
: mValue(
|
|
|
|
AsVariant(AnimationTransform{std::move(aTransformInDevSpace),
|
|
|
|
std::move(aFrameTransform), aData})) {}
|
2017-02-10 01:30:11 +03:00
|
|
|
|
2019-04-11 15:37:06 +03:00
|
|
|
explicit AnimatedValue(const float& aValue) : mValue(AsVariant(aValue)) {}
|
2018-11-28 03:59:15 +03:00
|
|
|
|
2019-04-11 15:37:06 +03:00
|
|
|
explicit AnimatedValue(nscolor aValue) : mValue(AsVariant(aValue)) {}
|
2017-02-10 01:30:11 +03:00
|
|
|
|
|
|
|
private:
|
2019-04-11 15:37:06 +03:00
|
|
|
AnimatedValueType mValue;
|
2017-02-10 01:30:11 +03:00
|
|
|
};
|
|
|
|
|
2017-09-22 23:39:53 +03:00
|
|
|
// CompositorAnimationStorage stores the animations and animated values
|
|
|
|
// keyed by a CompositorAnimationsId. The "animations" are a representation of
|
|
|
|
// an entire animation over time, while the "animated values" are values sampled
|
|
|
|
// from the animations at a particular point in time.
|
|
|
|
//
|
|
|
|
// There is one CompositorAnimationStorage per CompositorBridgeParent (i.e.
|
|
|
|
// one per browser window), and the CompositorAnimationsId key is unique within
|
|
|
|
// a particular CompositorAnimationStorage instance.
|
|
|
|
//
|
|
|
|
// Each layer which has animations gets a CompositorAnimationsId key, and reuses
|
|
|
|
// that key during its lifetime. Likewise, in layers-free webrender, a display
|
|
|
|
// item that is animated (e.g. nsDisplayTransform) gets a CompositorAnimationsId
|
|
|
|
// key and reuses that key (it persists the key via the frame user-data
|
|
|
|
// mechanism).
|
2017-02-10 01:30:11 +03:00
|
|
|
class CompositorAnimationStorage final {
|
|
|
|
typedef nsClassHashtable<nsUint64HashKey, AnimatedValue> AnimatedValueTable;
|
Bug 1425837 - Part 3: Don't store AnimationArray (a.k.a. AnimationInfo::mAnimations) on the compositor thread. r=birtles
The original implementation about "setting animations" is a little bit hard
to read. In `SetAnimations()`, we create a new intermediate data,
`AnimData`, and we mutate the original animations. And then iterate this
mutated animations & intermediate data for sampling. In this bug, we are
planning to group the AnimData as a useful data structure for supporting
multiple properties transform-like animations, so it seems the structure
of original animations may be hard to use after that. Therefore,
we decide to do some reworks on this:
First, we do renames,
1. InfalliableTArray to nsTArray. (They are the same.)
2. AnimData to PropertyAnimation.
3. SetAnimations() to ExtractAnimations(), which returns
nsTArray<PropertyAnimationGroup>. Each entry in the array is for one
property. In this patch, there is only one entry. We will extend this
to multiple entries in the next patch.
And then rework `ExtractAnimations()`, which stores all the necessary data
in `PropertyAnimationGroup`. For WR, we store this in
`CompositorAnimationStorage`. For non-WR, we store it in `AnimationInfo`.
So we can just use this organized data structure for supporting multiple
properties animations. (See the next patch.)
Depends on D22563
Differential Revision: https://phabricator.services.mozilla.com/D23062
--HG--
extra : moz-landing-system : lando
2019-03-18 21:04:48 +03:00
|
|
|
typedef nsClassHashtable<nsUint64HashKey, nsTArray<PropertyAnimationGroup>>
|
|
|
|
AnimationsTable;
|
2019-03-22 21:28:42 +03:00
|
|
|
typedef nsDataHashtable<nsUint64HashKey, wr::RenderRoot>
|
|
|
|
AnimationsRenderRootsTable;
|
2017-02-10 01:30:11 +03:00
|
|
|
|
|
|
|
NS_INLINE_DECL_THREADSAFE_REFCOUNTING(CompositorAnimationStorage)
|
2017-01-25 05:51:30 +03:00
|
|
|
public:
|
2017-02-10 01:30:11 +03:00
|
|
|
/**
|
2017-04-25 06:52:44 +03:00
|
|
|
* Set the animation transform based on the unique id and also
|
|
|
|
* set up |aFrameTransform| and |aData| for OMTA testing
|
2017-02-10 01:30:11 +03:00
|
|
|
*/
|
|
|
|
void SetAnimatedValue(uint64_t aId, gfx::Matrix4x4&& aTransformInDevSpace,
|
|
|
|
gfx::Matrix4x4&& aFrameTransform,
|
|
|
|
const TransformData& aData);
|
|
|
|
|
2017-04-25 06:52:44 +03:00
|
|
|
/**
|
|
|
|
* Set the animation transform in device pixel based on the unique id
|
|
|
|
*/
|
|
|
|
void SetAnimatedValue(uint64_t aId, gfx::Matrix4x4&& aTransformInDevSpace);
|
|
|
|
|
2017-02-10 01:30:11 +03:00
|
|
|
/**
|
|
|
|
* Set the animation opacity based on the unique id
|
|
|
|
*/
|
|
|
|
void SetAnimatedValue(uint64_t aId, const float& aOpacity);
|
|
|
|
|
2018-11-28 03:59:15 +03:00
|
|
|
/**
|
|
|
|
* Set the animation color based on the unique id
|
|
|
|
*/
|
|
|
|
void SetAnimatedValue(uint64_t aId, nscolor aColor);
|
|
|
|
|
2017-02-10 01:30:11 +03:00
|
|
|
/**
|
|
|
|
* Return the animated value if a given id can map to its animated value
|
|
|
|
*/
|
|
|
|
AnimatedValue* GetAnimatedValue(const uint64_t& aId) const;
|
|
|
|
|
2018-07-31 00:13:15 +03:00
|
|
|
OMTAValue GetOMTAValue(const uint64_t& aId) const;
|
|
|
|
|
2017-04-12 11:40:48 +03:00
|
|
|
/**
|
|
|
|
* Return the iterator of animated value table
|
|
|
|
*/
|
|
|
|
AnimatedValueTable::Iterator ConstAnimatedValueTableIter() const {
|
|
|
|
return mAnimatedValues.ConstIter();
|
|
|
|
}
|
|
|
|
|
|
|
|
uint32_t AnimatedValueCount() const { return mAnimatedValues.Count(); }
|
|
|
|
|
2017-02-10 01:30:11 +03:00
|
|
|
/**
|
|
|
|
* Set the animations based on the unique id
|
|
|
|
*/
|
2019-03-22 21:28:42 +03:00
|
|
|
void SetAnimations(uint64_t aId, const AnimationArray& aAnimations,
|
|
|
|
wr::RenderRoot aRenderRoot);
|
2017-02-10 01:30:11 +03:00
|
|
|
|
|
|
|
/**
|
|
|
|
* Return the animations if a given id can map to its animations
|
|
|
|
*/
|
Bug 1425837 - Part 3: Don't store AnimationArray (a.k.a. AnimationInfo::mAnimations) on the compositor thread. r=birtles
The original implementation about "setting animations" is a little bit hard
to read. In `SetAnimations()`, we create a new intermediate data,
`AnimData`, and we mutate the original animations. And then iterate this
mutated animations & intermediate data for sampling. In this bug, we are
planning to group the AnimData as a useful data structure for supporting
multiple properties transform-like animations, so it seems the structure
of original animations may be hard to use after that. Therefore,
we decide to do some reworks on this:
First, we do renames,
1. InfalliableTArray to nsTArray. (They are the same.)
2. AnimData to PropertyAnimation.
3. SetAnimations() to ExtractAnimations(), which returns
nsTArray<PropertyAnimationGroup>. Each entry in the array is for one
property. In this patch, there is only one entry. We will extend this
to multiple entries in the next patch.
And then rework `ExtractAnimations()`, which stores all the necessary data
in `PropertyAnimationGroup`. For WR, we store this in
`CompositorAnimationStorage`. For non-WR, we store it in `AnimationInfo`.
So we can just use this organized data structure for supporting multiple
properties animations. (See the next patch.)
Depends on D22563
Differential Revision: https://phabricator.services.mozilla.com/D23062
--HG--
extra : moz-landing-system : lando
2019-03-18 21:04:48 +03:00
|
|
|
nsTArray<PropertyAnimationGroup>* GetAnimations(const uint64_t& aId) const;
|
2017-02-10 01:30:11 +03:00
|
|
|
|
2017-04-12 11:40:48 +03:00
|
|
|
/**
|
|
|
|
* Return the iterator of animations table
|
|
|
|
*/
|
|
|
|
AnimationsTable::Iterator ConstAnimationsTableIter() const {
|
|
|
|
return mAnimations.ConstIter();
|
|
|
|
}
|
|
|
|
|
|
|
|
uint32_t AnimationsCount() const { return mAnimations.Count(); }
|
|
|
|
|
2019-03-22 21:28:42 +03:00
|
|
|
wr::RenderRoot AnimationRenderRoot(const uint64_t& aId) const {
|
|
|
|
return mAnimationRenderRoots.Get(aId);
|
|
|
|
}
|
|
|
|
|
2017-02-10 01:30:11 +03:00
|
|
|
/**
|
|
|
|
* Clear AnimatedValues and Animations data
|
|
|
|
*/
|
|
|
|
void Clear();
|
2017-04-12 11:40:48 +03:00
|
|
|
void ClearById(const uint64_t& aId);
|
2017-09-22 23:39:53 +03:00
|
|
|
|
2017-02-10 01:30:11 +03:00
|
|
|
private:
|
2017-07-06 06:06:41 +03:00
|
|
|
~CompositorAnimationStorage(){};
|
2017-02-10 01:30:11 +03:00
|
|
|
|
|
|
|
private:
|
|
|
|
AnimatedValueTable mAnimatedValues;
|
|
|
|
AnimationsTable mAnimations;
|
2019-03-22 21:28:42 +03:00
|
|
|
AnimationsRenderRootsTable mAnimationRenderRoots;
|
2017-02-10 01:30:11 +03:00
|
|
|
};
|
|
|
|
|
2017-09-22 23:39:53 +03:00
|
|
|
/**
|
|
|
|
* This utility class allows reusing code between the webrender and
|
|
|
|
* non-webrender compositor-side implementations. It provides
|
|
|
|
* utility functions for sampling animations at particular timestamps.
|
|
|
|
*/
|
2017-02-10 01:30:11 +03:00
|
|
|
class AnimationHelper {
|
|
|
|
public:
|
2018-04-24 03:27:54 +03:00
|
|
|
enum class SampleResult { None, Skipped, Sampled };
|
|
|
|
|
2017-09-22 23:39:53 +03:00
|
|
|
/**
|
2017-04-12 11:40:48 +03:00
|
|
|
* Sample animations based on a given time stamp for a element(layer) with
|
|
|
|
* its animation data.
|
2019-03-18 21:04:50 +03:00
|
|
|
* Generally |aPreviousFrameTime| is used for the sampling if it's
|
2018-05-08 06:58:42 +03:00
|
|
|
* supplied to make the animation more in sync with other animations on the
|
2018-05-08 10:58:06 +03:00
|
|
|
* main-thread. But in the case where the animation just started at the time
|
2019-03-18 21:04:50 +03:00
|
|
|
* when the animation was sent to the compositor, |aCurrentFrameTime| is used
|
|
|
|
* for sampling instead to avoid flicker.
|
2018-04-24 03:27:54 +03:00
|
|
|
*
|
|
|
|
* Returns SampleResult::None if none of the animations are producing a result
|
|
|
|
* (e.g. they are in the delay phase with no backwards fill),
|
|
|
|
* SampleResult::Skipped if the animation output did not change since the last
|
|
|
|
* call of this function,
|
|
|
|
* SampleResult::Sampled if the animation output was updated.
|
2019-03-18 21:04:50 +03:00
|
|
|
*
|
|
|
|
* Using the same example from ExtractAnimations (below):
|
|
|
|
*
|
|
|
|
* Input |aPropertyAnimationGroups| (ignoring the base animation style):
|
|
|
|
*
|
|
|
|
* [
|
|
|
|
* Group A: [ { rotate, Animation A }, { rotate, Animation B } ],
|
|
|
|
* Group B: [ { scale, Animation B } ],
|
|
|
|
* Group C: [ { transform, Animation A }, { transform, Animation B } ],
|
|
|
|
* ]
|
|
|
|
*
|
|
|
|
* For each property group, this function interpolates each animation in turn,
|
|
|
|
* using the result of interpolating one animation as input for the next such
|
|
|
|
* that it reduces each property group to a single output value:
|
|
|
|
*
|
|
|
|
* [
|
|
|
|
* { rotate, RawServoAnimationValue },
|
|
|
|
* { scale, RawServoAnimationValue },
|
|
|
|
* { transform, RawServoAnimationValue },
|
|
|
|
* ]
|
|
|
|
*
|
|
|
|
* For transform animations, the caller (SampleAnimations) will combine the
|
|
|
|
* result of the various transform properties into a final matrix.
|
2017-04-12 11:40:48 +03:00
|
|
|
*/
|
2018-05-08 06:58:42 +03:00
|
|
|
static SampleResult SampleAnimationForEachNode(
|
|
|
|
TimeStamp aPreviousFrameTime, TimeStamp aCurrentFrameTime,
|
2019-03-18 21:04:50 +03:00
|
|
|
const AnimatedValue* aPreviousValue,
|
Bug 1425837 - Part 3: Don't store AnimationArray (a.k.a. AnimationInfo::mAnimations) on the compositor thread. r=birtles
The original implementation about "setting animations" is a little bit hard
to read. In `SetAnimations()`, we create a new intermediate data,
`AnimData`, and we mutate the original animations. And then iterate this
mutated animations & intermediate data for sampling. In this bug, we are
planning to group the AnimData as a useful data structure for supporting
multiple properties transform-like animations, so it seems the structure
of original animations may be hard to use after that. Therefore,
we decide to do some reworks on this:
First, we do renames,
1. InfalliableTArray to nsTArray. (They are the same.)
2. AnimData to PropertyAnimation.
3. SetAnimations() to ExtractAnimations(), which returns
nsTArray<PropertyAnimationGroup>. Each entry in the array is for one
property. In this patch, there is only one entry. We will extend this
to multiple entries in the next patch.
And then rework `ExtractAnimations()`, which stores all the necessary data
in `PropertyAnimationGroup`. For WR, we store this in
`CompositorAnimationStorage`. For non-WR, we store it in `AnimationInfo`.
So we can just use this organized data structure for supporting multiple
properties animations. (See the next patch.)
Depends on D22563
Differential Revision: https://phabricator.services.mozilla.com/D23062
--HG--
extra : moz-landing-system : lando
2019-03-18 21:04:48 +03:00
|
|
|
nsTArray<PropertyAnimationGroup>& aPropertyAnimationGroups,
|
2019-03-18 21:04:50 +03:00
|
|
|
nsTArray<RefPtr<RawServoAnimationValue>>& aAnimationValues);
|
Bug 1425837 - Part 3: Don't store AnimationArray (a.k.a. AnimationInfo::mAnimations) on the compositor thread. r=birtles
The original implementation about "setting animations" is a little bit hard
to read. In `SetAnimations()`, we create a new intermediate data,
`AnimData`, and we mutate the original animations. And then iterate this
mutated animations & intermediate data for sampling. In this bug, we are
planning to group the AnimData as a useful data structure for supporting
multiple properties transform-like animations, so it seems the structure
of original animations may be hard to use after that. Therefore,
we decide to do some reworks on this:
First, we do renames,
1. InfalliableTArray to nsTArray. (They are the same.)
2. AnimData to PropertyAnimation.
3. SetAnimations() to ExtractAnimations(), which returns
nsTArray<PropertyAnimationGroup>. Each entry in the array is for one
property. In this patch, there is only one entry. We will extend this
to multiple entries in the next patch.
And then rework `ExtractAnimations()`, which stores all the necessary data
in `PropertyAnimationGroup`. For WR, we store this in
`CompositorAnimationStorage`. For non-WR, we store it in `AnimationInfo`.
So we can just use this organized data structure for supporting multiple
properties animations. (See the next patch.)
Depends on D22563
Differential Revision: https://phabricator.services.mozilla.com/D23062
--HG--
extra : moz-landing-system : lando
2019-03-18 21:04:48 +03:00
|
|
|
|
2017-09-22 23:39:53 +03:00
|
|
|
/**
|
Bug 1425837 - Part 3: Don't store AnimationArray (a.k.a. AnimationInfo::mAnimations) on the compositor thread. r=birtles
The original implementation about "setting animations" is a little bit hard
to read. In `SetAnimations()`, we create a new intermediate data,
`AnimData`, and we mutate the original animations. And then iterate this
mutated animations & intermediate data for sampling. In this bug, we are
planning to group the AnimData as a useful data structure for supporting
multiple properties transform-like animations, so it seems the structure
of original animations may be hard to use after that. Therefore,
we decide to do some reworks on this:
First, we do renames,
1. InfalliableTArray to nsTArray. (They are the same.)
2. AnimData to PropertyAnimation.
3. SetAnimations() to ExtractAnimations(), which returns
nsTArray<PropertyAnimationGroup>. Each entry in the array is for one
property. In this patch, there is only one entry. We will extend this
to multiple entries in the next patch.
And then rework `ExtractAnimations()`, which stores all the necessary data
in `PropertyAnimationGroup`. For WR, we store this in
`CompositorAnimationStorage`. For non-WR, we store it in `AnimationInfo`.
So we can just use this organized data structure for supporting multiple
properties animations. (See the next patch.)
Depends on D22563
Differential Revision: https://phabricator.services.mozilla.com/D23062
--HG--
extra : moz-landing-system : lando
2019-03-18 21:04:48 +03:00
|
|
|
* Extract organized animation data by property into an array of
|
2019-03-18 21:04:50 +03:00
|
|
|
* PropertyAnimationGroup objects.
|
|
|
|
*
|
|
|
|
* For example, suppose we have the following animations:
|
|
|
|
*
|
|
|
|
* Animation A: [ transform, rotate ]
|
|
|
|
* Animation B: [ rotate, scale ]
|
|
|
|
* Animation C: [ transform ]
|
|
|
|
* Animation D: [ opacity ]
|
|
|
|
*
|
|
|
|
* When we go to send transform-like properties to the compositor, we
|
|
|
|
* sort them as follows:
|
|
|
|
*
|
|
|
|
* [
|
|
|
|
* { rotate: Animation A (rotate segments only) },
|
|
|
|
* { rotate: Animation B ( " " ) },
|
|
|
|
* { scale: Animation B (scale segments only) },
|
|
|
|
* { transform: Animation A (transform segments only) },
|
|
|
|
* { transform: Animation C ( " " ) },
|
|
|
|
* ]
|
|
|
|
*
|
|
|
|
* In this function, we group these animations together by property producing
|
|
|
|
* output such as the following:
|
|
|
|
*
|
|
|
|
* [
|
|
|
|
* [ { rotate, Animation A }, { rotate, Animation B } ],
|
|
|
|
* [ { scale, Animation B } ],
|
|
|
|
* [ { transform, Animation A }, { transform, Animation B } ],
|
|
|
|
* ]
|
|
|
|
*
|
|
|
|
* In the process of grouping these animations, we also convert their values
|
|
|
|
* from the rather compact representation we use for transferring across the
|
|
|
|
* IPC boundary into something we can readily use for sampling.
|
2017-04-12 11:40:48 +03:00
|
|
|
*/
|
Bug 1425837 - Part 3: Don't store AnimationArray (a.k.a. AnimationInfo::mAnimations) on the compositor thread. r=birtles
The original implementation about "setting animations" is a little bit hard
to read. In `SetAnimations()`, we create a new intermediate data,
`AnimData`, and we mutate the original animations. And then iterate this
mutated animations & intermediate data for sampling. In this bug, we are
planning to group the AnimData as a useful data structure for supporting
multiple properties transform-like animations, so it seems the structure
of original animations may be hard to use after that. Therefore,
we decide to do some reworks on this:
First, we do renames,
1. InfalliableTArray to nsTArray. (They are the same.)
2. AnimData to PropertyAnimation.
3. SetAnimations() to ExtractAnimations(), which returns
nsTArray<PropertyAnimationGroup>. Each entry in the array is for one
property. In this patch, there is only one entry. We will extend this
to multiple entries in the next patch.
And then rework `ExtractAnimations()`, which stores all the necessary data
in `PropertyAnimationGroup`. For WR, we store this in
`CompositorAnimationStorage`. For non-WR, we store it in `AnimationInfo`.
So we can just use this organized data structure for supporting multiple
properties animations. (See the next patch.)
Depends on D22563
Differential Revision: https://phabricator.services.mozilla.com/D23062
--HG--
extra : moz-landing-system : lando
2019-03-18 21:04:48 +03:00
|
|
|
static nsTArray<PropertyAnimationGroup> ExtractAnimations(
|
|
|
|
const AnimationArray& aAnimations);
|
2017-04-12 11:40:48 +03:00
|
|
|
|
2017-09-22 23:39:53 +03:00
|
|
|
/**
|
2017-04-12 11:40:48 +03:00
|
|
|
* Get a unique id to represent the compositor animation between child
|
|
|
|
* and parent side. This id will be used as a key to store animation
|
|
|
|
* data in the CompositorAnimationStorage per compositor.
|
|
|
|
* Each layer on the content side calls this when it gets new animation
|
|
|
|
* data.
|
|
|
|
*/
|
2017-02-08 22:31:45 +03:00
|
|
|
static uint64_t GetNextCompositorAnimationsId();
|
2017-04-12 11:40:48 +03:00
|
|
|
|
2017-09-22 23:39:53 +03:00
|
|
|
/**
|
2017-04-12 11:40:48 +03:00
|
|
|
* Sample animation based a given time stamp |aTime| and the animation
|
|
|
|
* data inside CompositorAnimationStorage |aStorage|. The animated values
|
|
|
|
* after sampling will be stored in CompositorAnimationStorage as well.
|
2018-05-08 09:48:27 +03:00
|
|
|
*
|
|
|
|
* Returns true if there is any animation.
|
|
|
|
* Note that even if there are only in-delay phase animations (i.e. not
|
|
|
|
* visually effective), this function returns true to ensure we composite
|
|
|
|
* again on the next tick.
|
Bug 1425837 - Part 3: Don't store AnimationArray (a.k.a. AnimationInfo::mAnimations) on the compositor thread. r=birtles
The original implementation about "setting animations" is a little bit hard
to read. In `SetAnimations()`, we create a new intermediate data,
`AnimData`, and we mutate the original animations. And then iterate this
mutated animations & intermediate data for sampling. In this bug, we are
planning to group the AnimData as a useful data structure for supporting
multiple properties transform-like animations, so it seems the structure
of original animations may be hard to use after that. Therefore,
we decide to do some reworks on this:
First, we do renames,
1. InfalliableTArray to nsTArray. (They are the same.)
2. AnimData to PropertyAnimation.
3. SetAnimations() to ExtractAnimations(), which returns
nsTArray<PropertyAnimationGroup>. Each entry in the array is for one
property. In this patch, there is only one entry. We will extend this
to multiple entries in the next patch.
And then rework `ExtractAnimations()`, which stores all the necessary data
in `PropertyAnimationGroup`. For WR, we store this in
`CompositorAnimationStorage`. For non-WR, we store it in `AnimationInfo`.
So we can just use this organized data structure for supporting multiple
properties animations. (See the next patch.)
Depends on D22563
Differential Revision: https://phabricator.services.mozilla.com/D23062
--HG--
extra : moz-landing-system : lando
2019-03-18 21:04:48 +03:00
|
|
|
*
|
|
|
|
* Note: This is called only by WebRender.
|
2017-04-12 11:40:48 +03:00
|
|
|
*/
|
|
|
|
static bool SampleAnimations(CompositorAnimationStorage* aStorage,
|
2018-05-08 06:58:42 +03:00
|
|
|
TimeStamp aPreviousFrameTime,
|
|
|
|
TimeStamp aCurrentFrameTime);
|
2019-03-18 21:04:46 +03:00
|
|
|
|
|
|
|
/**
|
2019-03-18 21:04:50 +03:00
|
|
|
* Convert an array of animation values into a matrix given the corresponding
|
|
|
|
* transform parameters. |aValue| must be a transform-like value
|
|
|
|
* (e.g. transform, translate etc.).
|
2019-03-18 21:04:46 +03:00
|
|
|
*/
|
|
|
|
static gfx::Matrix4x4 ServoAnimationValueToMatrix4x4(
|
2019-03-18 21:04:50 +03:00
|
|
|
const nsTArray<RefPtr<RawServoAnimationValue>>& aValue,
|
2019-03-18 21:04:46 +03:00
|
|
|
const TransformData& aTransformData);
|
2017-01-25 05:51:30 +03:00
|
|
|
};
|
|
|
|
|
|
|
|
} // namespace layers
|
|
|
|
} // namespace mozilla
|
|
|
|
|
|
|
|
#endif // mozilla_layers_AnimationHelper_h
|