New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CSS-like Animations & Transitions #1461

merged 89 commits into from May 26, 2018


None yet
4 participants

jmacato commented Mar 21, 2018

This PR tracks our attempt at implementing a CSS-like Style-definable Keyframe Animations and Property Transitions for Avalonia.


  • Extensive unit-tests (that will be filed after this PR).
  • Alternative KeyFrame interpolation algorithms (Splines, Bezier, etc.)

To-do list

Property Transitions

  • Style-declared Transitions
  • Control-declared Transitions
  • Numerical (Double, Float, Integer) Transitions
    SolidColorBrush Transition Will be on a future PR.


  • Style-declared Animations
  • Proper Class Triggering behavior
  • Global Animations Timer with controllable play states
  • Key frames
    • Generic KeyFrame objects
    • Numerical (Double, Float, Integer) Keyframes Animations
      Color (SolidColorBrush) Keyframes Animation Will be on a future PR.
  • Controllable Play state on every Animatable-derived controls.
  • Repeat Behavior
  • Fill modes (similar to this)


  • Rework PageTransitions to use the new animations backend.
  • Rework ProgressBar's indeterminate state animation.

Fixes #778

jmacato and others added some commits Mar 21, 2018

Rename Carousel & TabControls Transition property to PageTransitions …
…to avoid confusion to the upcoming Transitions from Avalonia.Animations.
*Added initial implementation of new Transitions
*Added default easing classes
*Added easing type converter
*Added initial implementation of new Transitions
*Added default easing classes
*Added easing type converter
*Added numerical transition classes.
*Disabled old animations code in CrossFade, PageSlide, CarouselPresenter and ProgressBar.
Revert the library split, just transferring the base Animatable class…
… to Avalonia.Visual was good enough.

Apply important changes from my internal test branch
Made visuals depend on animations.
Instead of `Avalonia.Animations` depending on `Avalonia.Visuals`, make it the other way round.
*Implement Basic Keyframe Animations support.
*Implement DoubleKeyFrames for Properties such as Opacity, etc.
*Implement TransformKeyFrames with initial implementation
 of specialized logic for selecting RenderTransform of the
 target control properly.
*Ported RenderTest to .NET Core for testing and to remove the
 crufty old .csproj format.
*Replaced AnimationsPage with some samples of hover-activated
 animated red rectangles.
* Fixed interpolation point selection when theres three or more keyfr…

*Added new examples in RenderTest/AnimationsPage
* Transfer some keyframe handling responsibilites to the base class f…
…or maximum reusability on later custom derived classes.

* Fix flickering issues on restart in TransformKeyFrames.

*Add some syntactic sugar here and there.
Pass target control to the keyframes and other animation classes.
Make the global timer discrete to avoid costly TimeSpan conversions and enable global animation pause/play support.
Split the global timer for Transitions and Animations.
Added more example animations in RenderTest with Global Pause/Resume button for Animations.
TransitionKeyFrames transform selection logic are now fully functional.
Trigger RaiseChanged() on TransformGroup class when a child transform was changed.

Split the PlayState enum to a new file.
Some tweaking with AnimationPage.xaml.
Merged RenderTest's Program and App class for brevity.
- Initial implementation of ColorTransition.cs
- Added System.Numerics.Vectors in Avalonia.Base.
- Replaced AnimationPlayState in Animatable.cs with a DirectProperty.

jmacato added some commits May 18, 2018

Fix extraneous empty lines.
Fix Animation.cs braces

This comment has been minimized.


jmacato commented May 18, 2018

Should i add uniform properties to the transforms now (Scale in addition with ScaleX & ScaleY, etc) ?
It wouldn't be a problem to rework the syntax to that but I'll need input on the implementation details later on


This comment has been minimized.


grokys commented May 18, 2018

Let's worry about the Scale, ScaleX, ScaleY stuff later I think, it shouldn't change anything here I don't think.

jmacato added some commits May 18, 2018

Fix all remaining nits - this commit will be used as a breakpoint for…
… the upcoming syntax reimplementation.

This comment has been minimized.


jmacato commented May 24, 2018

Done doing a rough reimplementation of the new syntax as suggested by @grokys & @danwalmsley

jmacato added some commits May 25, 2018

Nits addressed!


grokys approved these changes May 26, 2018


This comment has been minimized.


grokys commented May 26, 2018

Looks great! Once #1594 has been merged we should be able to use the standard <Setter> instead of <DoubleSetter>, but I don't want to hold this up waiting for that!

@grokys grokys merged commit 0c36c1b into AvaloniaUI:master May 26, 2018

2 checks passed

continuous-integration/appveyor/pr AppVeyor build succeeded
continuous-integration/travis-ci/pr The Travis CI build passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment