tree: 6f2c2d77738b95f34445709d76c575186d05aced [path history] [tgz]
  1. animation.cc
  2. animation.h
  3. animation_curve.cc
  4. animation_curve.h
  5. animation_delegate.h
  6. animation_events.cc
  7. animation_events.h
  8. animation_export.h
  9. animation_host.cc
  10. animation_host.h
  11. animation_host_perftest.cc
  12. animation_host_unittest.cc
  13. animation_id_provider.cc
  14. animation_id_provider.h
  15. animation_target.h
  16. animation_timeline.cc
  17. animation_timeline.h
  18. animation_timeline_unittest.cc
  19. animation_unittest.cc
  20. BUILD.gn
  21. DEPS
  22. element_animations.cc
  23. element_animations.h
  24. element_animations_unittest.cc
  25. keyframe_effect.cc
  26. keyframe_effect.h
  27. keyframe_model.cc
  28. keyframe_model.h
  29. keyframe_model_unittest.cc
  30. keyframed_animation_curve.cc
  31. keyframed_animation_curve.h
  32. keyframed_animation_curve_unittest.cc
  33. README.md
  34. scroll_offset_animation_curve.cc
  35. scroll_offset_animation_curve.h
  36. scroll_offset_animation_curve_unittest.cc
  37. scroll_offset_animations.cc
  38. scroll_offset_animations.h
  39. scroll_offset_animations_impl.cc
  40. scroll_offset_animations_impl.h
  41. scroll_timeline.cc
  42. scroll_timeline.h
  43. scroll_timeline_unittest.cc
  44. single_keyframe_effect_animation.cc
  45. single_keyframe_effect_animation.h
  46. timing_function.cc
  47. timing_function.h
  48. transform_operation.cc
  49. transform_operation.h
  50. transform_operations.cc
  51. transform_operations.h
  52. transform_operations_unittest.cc
  53. worklet_animation.cc
  54. worklet_animation.h
  55. worklet_animation_unittest.cc
cc/animation/README.md

cc/animation

Overview

cc/animation provides animation support - generating output values (usually visual properties) based on a predefined function and changing input values. Currently the main clients of cc/animation are Blink and ui/, targeting composited layers, but the code is intended to be agnostic of the client it is supporting. Aspirationally we could eventually merge cc/animation and Blink animation and have only a single animation system for all of Chromium.

This document covers two main topics. The first section explains how cc/animation actually works: how animations are ticked, what animation curves are, what the ownership model is, etc. Later sections document how other parts of Chromium interact with cc/animation, most prominently Blink and ui/.

How cc/animation works

The root concept in cc/animation is an keyframe model. Animations contain the state necessary to ‘play’ (interpolate values from) an animation curve, which is a function that returns a value given an input time. Aside from the animation curve itself, an animation's state includes the run state (playing, paused, etc), the start time, the current direction (forwards, reverse), etc. An animation does not know or care what property is being animated, and holds only an opaque identifier for the property to allow clients to map output values to the correct properties.

Targeting only a single property means that cc KeyframeModels are distinct from the Blink concept of an animation, which wraps the animation of multiple properties. To coordinate the playback of multiple cc/animations (e.g. those that are animating multiple properties on the same target), KeyframeModels have the concept of a group identifier. Animations that have the same group identifier and the same target are started together, and animation-finished notifications are only sent when all animations in the group have finished.

Animations are grouped together based on their animation target (the entity whose property is being animated) and each such group is owned by an animation. Note that there may be multiple animations with the same target (each with a set of KeyframeModels for that target); the ElementAnimations class wraps the multiple animations and has a 1:1 relationship with target entities.

TODO(smcgruer): Why are ElementAnimations and Animations separate?

In order to play an animation, input time values must be provided to the animation curve and output values fed back into the animating entity. This is called ‘ticking’ an animation and is the responsibility of the animation host. The animation host has a list of currently ticking animations (i.e. those that have any non-deleted animations), which it iterates through whenever it receives a tick call from the client (along with a corresponding input time). The animations then call into their non-deleted animations, retrieving the value from the animation curve. As they are computed, output values are sent to the target which is responsible for passing them to the client entity that is being animated.

Types of Animation Curve

As noted above, an animation curve is simply a function which converts an input time value into some output value. Animation curves are categorized based on their output type, and each such category can have multiple implementations that provide different conversion functions. There are many categories of animation curve, but some common ones are FloatAnimationCurve, ColorAnimationCurve, and TransformAnimationCurve.

The most common implementation of the various animation curve categories are the keyframed animation curves. These curves each have a set of keyframes which map a specific time to a specific output value. Producing an output value for a given input time is then a matter of identifying the two keyframes the time lies between, and interpolating between the keyframe output values. (Or simply using a keyframe output value directly, if the input time happens to line up exactly.) Exact details of how each animation curve category is interpolated can be found in the implementations.

There is one category of animation curve that stands somewhat apart, the scroll offset animation curve. This curve converts the input time into a scroll offset, interpolating between an initial scroll offset and an updateable target scroll offset. It has logic to handle different types of scrolling such as programmatic, keyboard, and mouse wheel scrolls.

Animation Timelines

cc/animation has a concept of an animation timeline. This should not be confused with the identically named Blink concept. In cc/animation, animation timelines are an implementation detail - they hold the animations and are responsible for syncing them to the impl thread (see below), but do not participate in the ticking process in any way.

Main/Impl Threads

One part of cc/animation that is not client agnostic is its support for the Chromium compositor thread. Most of the cc/animation classes have a PushPropertiesTo method, in which they synchronize necessary state from the main thread to the impl thread. It is feasible that such support could be abstracted if necessary, but so far it has not been required.

Current cc/animation Clients

As noted above, the main clients of cc/animation are currently Blink for accelerated web animations, and ui/ for accelerated user interface animations. Both of these clients utilize cc::Layer as their animation entity and interact with cc/animation via the MutatorHostClient interface (which is implemented by cc::LayerTreeHost and cc::LayerTreeHostImpl). Recently a third client, chrome/browser/vr/, has started using cc/animations as well. The vr/ client does not use cc::Layer as its animation entity.

TODO(smcgruer): Summarize how vr/ uses cc/animation.

Supported Animatable Properties

As cc::Layers are just textures which are reused for performance, clients that use composited layers as their animation entities are limited to animating properties that do not cause content to be redrawn. For example, a composited layer's opacity can be animated as promoted layers are aware of the content behind them. On the other hand we cannot animate layer width as changing the width could modify layout - which then requires redrawing.

Interaction between cc/animation and Blink

Blink is able to move compatible animations off the main thread by promoting the animating element into a layer. The Blink Lifetime of a compositor animation document describes how composited animations are created in blink. Once a compositor animation is created it is pushed through the commit cycle.

The lifetime of a newly started cc::Animation is roughly the following:

  1. blink::DocumentAnimations::UpdateAnimations calls blink::Animation::PreCommit on each pending blink::Animation constructing the corresponding cc::Animation via blink::Animation::CreateCompositorAnimation (attaching the animation to the cc::AnimationTimeline resulting in it being later pushed). The KeyframeEffects are constructed via blink::Animation::StartAnimationOnCompositor.
  2. AnimationHost::RegisterKeyframeEffectForElement creates a cc::ElementAnimations for the target element_id if one does not already exist. This ElementAnimations instance is shared by all animations with the same target and tracks the existence of the target.
  3. During the commit, cc::ElementAnimations::ElementRegistered is called on the main thread's AnimationHost either:
    • Before BlinkGenPropertyTrees, when a layer with the target element_id is registered.
    • After BlinkGenPropertyTrees, after a property tree node with the target element_id is created on the main thread LayerTreeHost's property_trees_. This begins ticking the attached KeyframeEffects and tracks that the element exists in the active layer / property tree.
  4. cc::LayerTreeHost::FinishCommitOnImplThread calls cc::AnimationHost::PushPropertiesTo which results in cc::AnimationTimeline::PushAttachedAnimationsToImplThread creating a cc::Animation on the compositor thread's AnimationTimeline for each animation missing from the compositor thread.
  5. cc::Animation::PushPropertiesTo is called on every animation on the timeline. When the element_id is pushed by cc::KeyframeEffect::PushPropertiesTo cc::Animation::AttachElementForKeyframeEffect creates a compositor side cc::ElementAnimations instance to track the existence of the element on the compositor. Since animations are pushed after the layer and property trees, the element should already exist on the pending tree. This will result in the animation being added to the ticking animations list.
  6. Now the animation is ticking, meaning that cc::Animation::Tick will be called every frame and update the pending property tree nodes.
  7. When the pending tree is activated, cc::AnimationHost::ActivateAnimations updates the keyframe effects and cc::ElementAnimations::ElementRegistered is called for the newly added element id on the active tree, setting has_element_in_active_list_.
  8. Subsequent animation ticks will now update the property nodes on the active tree.

TODO(flackr): Document finishing / cancel / abort.

Interaction between cc/animation and ui/

TODO(smcgruer): Write this.

Additional References

The Compositor Property Trees talk slides includes discussion on compositor animations.

The Project Heaviside design document and slides provide history on the Chromium and Blink animation system. The slides in particular include helpful software architecture diagrams.

Smooth scrolling is implemented via animations. See also references to “scroll offset” animations in the cc code base. Smooth Scrolling in Chromium provides an overview of smooth scrolling. There is further class header documentation in Blink's platform/scroll directory.