2017-10-28 02:10:06 +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
|
2017-07-21 09:21:47 +03:00
|
|
|
* 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 GFX_ANIMATIONINFO_H
|
|
|
|
#define GFX_ANIMATIONINFO_H
|
|
|
|
|
2018-04-19 07:50:14 +03:00
|
|
|
#include "nsAutoPtr.h"
|
2018-11-13 13:23:20 +03:00
|
|
|
#include "nsCSSPropertyIDSet.h"
|
2018-04-06 17:06:54 +03:00
|
|
|
#include "nsDisplayItemTypes.h"
|
2018-11-13 13:23:20 +03:00
|
|
|
#include "mozilla/Array.h"
|
2017-07-21 09:21:47 +03:00
|
|
|
|
2018-04-19 07:50:14 +03:00
|
|
|
struct RawServoAnimationValue;
|
2018-11-13 13:23:20 +03:00
|
|
|
class nsIContent;
|
2018-04-19 07:50:14 +03:00
|
|
|
class nsIFrame;
|
|
|
|
|
2017-07-21 09:21:47 +03:00
|
|
|
namespace mozilla {
|
|
|
|
namespace layers {
|
|
|
|
|
|
|
|
class Animation;
|
|
|
|
class CompositorAnimations;
|
|
|
|
class Layer;
|
|
|
|
class LayerManager;
|
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
|
|
|
struct PropertyAnimationGroup;
|
2017-07-21 09:21:47 +03:00
|
|
|
|
2018-11-07 06:09:05 +03:00
|
|
|
class AnimationInfo final {
|
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<Animation> AnimationArray;
|
2018-11-30 13:46:48 +03:00
|
|
|
|
2017-07-21 09:21:47 +03:00
|
|
|
public:
|
2018-11-07 06:09:05 +03:00
|
|
|
AnimationInfo();
|
|
|
|
~AnimationInfo();
|
2017-07-21 09:21:47 +03:00
|
|
|
|
|
|
|
// Ensure that this AnimationInfo has a valid (non-zero) animations id. This
|
|
|
|
// value is unique across layers.
|
|
|
|
void EnsureAnimationsId();
|
|
|
|
|
|
|
|
// Call AddAnimation to add a new animation to this layer from layout code.
|
|
|
|
// Caller must fill in all the properties of the returned animation.
|
|
|
|
// A later animation overrides an earlier one.
|
|
|
|
Animation* AddAnimation();
|
|
|
|
|
|
|
|
// These are a parallel to AddAnimation and clearAnimations, except
|
|
|
|
// they add pending animations that apply only when the next
|
|
|
|
// transaction is begun. (See also
|
|
|
|
// SetBaseTransformForNextTransaction.)
|
|
|
|
Animation* AddAnimationForNextTransaction();
|
|
|
|
|
2018-11-07 06:13:04 +03:00
|
|
|
void SetAnimationGeneration(uint64_t aCount) {
|
|
|
|
mAnimationGeneration = Some(aCount);
|
|
|
|
}
|
2018-11-13 13:17:34 +03:00
|
|
|
Maybe<uint64_t> GetAnimationGeneration() const {
|
|
|
|
return mAnimationGeneration;
|
|
|
|
}
|
2017-07-21 09:21:47 +03:00
|
|
|
|
|
|
|
// ClearAnimations clears animations on this layer.
|
|
|
|
void ClearAnimations();
|
|
|
|
void ClearAnimationsForNextTransaction();
|
|
|
|
void SetCompositorAnimations(
|
|
|
|
const CompositorAnimations& aCompositorAnimations);
|
|
|
|
bool StartPendingAnimations(const TimeStamp& aReadyTime);
|
|
|
|
void TransferMutatedFlagToLayer(Layer* aLayer);
|
|
|
|
|
|
|
|
uint64_t GetCompositorAnimationsId() { return mCompositorAnimationsId; }
|
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: We don't set mAnimations on the compositor thread, so this will
|
|
|
|
// always return an empty array on the compositor thread.
|
2017-07-21 09:21:47 +03:00
|
|
|
AnimationArray& GetAnimations() { return mAnimations; }
|
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>& GetPropertyAnimationGroups() {
|
|
|
|
return mPropertyAnimationGroups;
|
|
|
|
}
|
2017-07-21 09:21:47 +03:00
|
|
|
bool ApplyPendingUpdatesForThisTransaction();
|
|
|
|
bool HasTransformAnimation() const;
|
|
|
|
|
2018-05-07 04:50:40 +03:00
|
|
|
// In case of continuation, |aFrame| must be the first or the last
|
|
|
|
// continuation frame, otherwise this function might return Nothing().
|
2018-04-06 17:06:54 +03:00
|
|
|
static Maybe<uint64_t> GetGenerationFromFrame(
|
|
|
|
nsIFrame* aFrame, DisplayItemType aDisplayItemKey);
|
|
|
|
|
2018-11-13 13:23:20 +03:00
|
|
|
using CompositorAnimatableDisplayItemTypes =
|
2019-03-18 21:05:00 +03:00
|
|
|
Array<DisplayItemType,
|
|
|
|
nsCSSPropertyIDSet::CompositorAnimatableDisplayItemCount()>;
|
2018-11-13 13:23:20 +03:00
|
|
|
using AnimationGenerationCallback = std::function<bool(
|
|
|
|
const Maybe<uint64_t>& aGeneration, DisplayItemType aDisplayItemType)>;
|
|
|
|
// Enumerates animation generations on |aFrame| for the given display item
|
|
|
|
// types and calls |aCallback| with the animation generation.
|
|
|
|
//
|
|
|
|
// The enumeration stops if |aCallback| returns false.
|
|
|
|
static void EnumerateGenerationOnFrame(
|
|
|
|
const nsIFrame* aFrame, const nsIContent* aContent,
|
|
|
|
const CompositorAnimatableDisplayItemTypes& aDisplayItemTypes,
|
|
|
|
const AnimationGenerationCallback& aCallback);
|
|
|
|
|
2017-07-21 09:21:47 +03:00
|
|
|
protected:
|
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
|
|
|
// mAnimations (and mPendingAnimations) are only set on the main thread.
|
|
|
|
//
|
|
|
|
// Once the animations are received on the compositor thread/process we
|
|
|
|
// use AnimationHelper::ExtractAnimations to transform the rather compact
|
|
|
|
// representation of animation data we transfer into something we can more
|
|
|
|
// readily use for sampling and then store it in mPropertyAnimationGroups
|
|
|
|
// (below) or CompositorAnimationStorage.mAnimations for WebRender.
|
2017-07-21 09:21:47 +03:00
|
|
|
AnimationArray mAnimations;
|
|
|
|
nsAutoPtr<AnimationArray> mPendingAnimations;
|
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
|
|
|
|
|
|
|
uint64_t mCompositorAnimationsId;
|
|
|
|
// The extracted data produced by AnimationHelper::ExtractAnimations().
|
|
|
|
//
|
|
|
|
// Each entry in the array represents an animation list for one property. For
|
|
|
|
// transform-like properties (e.g. transform, rotate etc.), there may be
|
|
|
|
// multiple entries depending on how many transform-like properties we have.
|
|
|
|
nsTArray<PropertyAnimationGroup> mPropertyAnimationGroups;
|
2017-07-21 09:21:47 +03:00
|
|
|
// If this layer is used for OMTA, then this counter is used to ensure we
|
|
|
|
// stay in sync with the animation manager
|
2018-11-07 06:13:04 +03:00
|
|
|
Maybe<uint64_t> mAnimationGeneration;
|
2017-07-21 09:21:47 +03:00
|
|
|
bool mMutated;
|
|
|
|
};
|
|
|
|
|
|
|
|
} // namespace layers
|
|
|
|
} // namespace mozilla
|
|
|
|
|
|
|
|
#endif // GFX_ANIMATIONINFO_H
|