A DoubleAnimation enables you to animate a single property value from one doubleprecision floating-point value to another. This is probably the most widely used type of animation. To illustrate a DoubleAnimation, this example shows how you could fade out the Ellipse defined in listing 22.2 over one second:

<DoubleAnimation Storyboard.TargetName="myEllipse"
                 Storyboard.TargetProperty="Opacity"
                 From="1" To="0"
                 Duration="0:0:1" />

As this markup illustrates, delivering a fade effect is incredibly simple. The DoubleAnimation element prepares Silverlight to generate double-precision values between the From and To values. As you can imagine, this opens the doors to tons of animation scenarios, but not every opened door should necessarily be entered.

Attempting to animate the FontSize property of a TextBlock can be a resourceconsuming task. Even though this property is implemented as a double-precision value, animating it can quickly lead to poorly performing applications because the text will be smoothed on every frame—an expensive process, even when the text is using animation-optimized smoothing. For this reason, if you need to animate your text, you may want to consider converting your TextBlock into a Path and using a ScaleTransform.

Regardless, the DoubleAnimation is still applicable in a variety of scenarios: creating fades, moving elements around a Panel, and performing transformations, among other things. However useful the DoubleAnimation is, there still may be situations where you need to animate Point-related values.

The PointAnimation type enables you to animate from one pair of x and y coordinates to another. As the name implies, this type of animation enables you to animate any property that represents a System.Windows.Point. And although this type isn't as widely used throughout the Silverlight APIs as the double type, it still has its place. For instance, you may need to animate the center of an EllipseGeometry object or dynamically change the presentation of a brush. Regardless of the need, it's nice to know that you can rely on the PointAnimation, which is illustrated here:

<PointAnimation Storyboard.TargetProperty="Center"
                Storyboard.TargetName="EllipseGeometry"
                Duration="0:0:2"
                From="100,100"
                To="100,300" />

The animation in this example changes the origin of any transforms applied to the Ellipse in listing 22.2. Generally, a PointAnimation will only be used in association with transforms and the Geometry elements mentioned in chapter 18. But, for a more subtle animation, you may consider using a ColorAnimation.

A ColorAnimation enables you to create smooth transitions from one color to another. These transitions can be performed between any two System.Windows. Media.Color property values. For this reason, this type of animation is used primarily with a brush as shown in this example:

<ColorAnimation Storyboard.TargetName="myEllipse"
           Storyboard.TargetProperty="(Fill).(SolidColorBrush.Color)"
           Duration="00:00:01"
           From="Yellow" To="Red" />

This XAML shows an assumed Ellipse shifting from Yellow to Red over the course of one second. This animation, along with the others mentioned, shows how easy it is to animate a property. Up to this point, we've only focused on animation related to a property type. In reality you also need to know how to specify the exact property you're animating.

Each of the animation types that we've discussed exposes two attached properties that specify the target of an animation. Appropriately, these attributes are called Storyboard. TargetProperty and Storyboard.TargetName. These properties work in coordination to determine which property of a specific element will be animated. This is a simplified description of these properties; a more detailed definition will be provided in section 22.3.2. For now, let's turn our focus to the second question in our animation journey.

There's a saying that you can't know where you're going until you know where you've been. In regard to animation, this phrase should be changed to you can't know where you're going unless you know where you're from. To identify where an animation is coming from, you rely on the aptly named From property.

The From property is accessible from all the animation types that we've discussed. This value determines where an animation will begin. The following XAML shows the From property in action to help jump start our discussion:

<DoubleAnimation Storyboard.TargetName="myImage"
                 Storyboard.TargetProperty="Opacity"
                 From="0" To="1"
                 Duration="0:0:1" />
...
<Image x:Name="myImage"
       Source=" http://www.silverlightinaction.com/man.png"
       Opacity=".25" />

This example is preparing to animate the Opacity property of an assumed Image. The Opacity property of this Image is initially set to 0 when the animation starts. This is determined by the value provided within the From property. Once the animation begins, the Opacity value gradually increases over the course of one second to the value of 1.

Note that this value is compatible with the animation type. The 0 may look like an integer, but at runtime, it's automatically converted into a double-precision value. If you'd attempted to set the From property value to Yellow, an exception would've been thrown because Yellow isn't a valid double-precision value. Alternatively, you can skip this potential problem altogether by not defining a From property value; the From property is an optional attribute.

If a From value isn't provided, the animation will automatically decide where to start from. To decide where to begin, the animation will examine the target specified by the Storyboard.TargetName and Storyboard.TargetProperty attributes. Once these are examined, the From property will be set to the current property value associated with the target, as shown in this example:

<DoubleAnimation Storyboard.TargetName="myImage"
                 Storyboard.TargetProperty="Opacity"
                 To="1" Duration="0:0:1" />
...
<Image x:Name="myImage"
       Source=" http://www.silverlightinaction.com/man.png"
       Opacity=".25" />

When the animation in this markup begins, it automatically determines that the Opacity value within the animation should begin at .25. This is the current value of the Opacity property, which is defined as the target. This approach can help create smoother, more fluid animations. On the other hand, explicitly stating the From value can have unexpected effects on your animations.

Explicitly setting the From value can cause your animations to jump or jerk between iterations because the animation may need to reset the target property back to the value set within the From attribute. If you want more fluid animations, you may consider having an animation end at, or just before, the value specified within the From value. Alternatively, you may choose to skip setting the From value altogether. Either way, you need to know where the animation is going.

One way to predetermine where an animation is going is by setting the To property. The To property is exposed within the ColorAnimation, DoubleAnimation, and PointAnimation types. This value represents the destination of a specific animation. Like the From property, the value associated with the To property must be compatible with the type of animation. To get a better feel for this property, examine its use in this example:

<DoubleAnimation Storyboard.TargetProperty="Opacity"
                 Storyboard.TargetName="myEllipse"
                 Duration="0:0:1"
                 From=".75" To="0" />

This XAML shows the Opacity of the Ellipse changing from .75 to 0 when the animation begins. Over the course of one second, the Opacity of the Ellipse will change to 0. If you've defined a value for the From attribute, you don't have to set the To property. Instead, you can rely on the use of the By property.

The By property is a special shortcut that provides an alternate to the To property. Instead of having to know where you want to go initially, you can conveniently specify a value in the By attribute. When the animation is run, Silverlight adds the value defined in the From field to the By value to automatically determine the To value. To get a firmer understanding of how this can be used, take a look at this markup:

<DoubleAnimation Storyboard.TargetName="myImage"
                 Storyboard.TargetProperty="Opacity"
                 From=".25" By=".50"
                 Duration="0:0:1" />

This example defines the animation for an assumed Image. When the animation begins, the Opacity property of the Image is set to .25. Over the course of one second, you want this animation to increase the Opacity value by .50. When this animation has started, the To value will essentially be .75. You can also decrease the Opacity value by providing a negative value, as shown in this XAML fragment:

<DoubleAnimation Storyboard.TargetName="myImage"
                 Storyboard.TargetProperty="Opacity"
                 From=".25" By="-.10"
                 Duration="0:0:1" />

This markup shows the alternative to increasing a value. Note that the By property itself is an alternative to the To property. If both properties are defined, the To property will take precedence and the By property will be ignored.

The By and To properties enable you to provide guidance for your animations. These animations begin at the value provided within the From field. To determine how long the animation should take to get to the destination, we have one final question to address.

The Duration property specifies how long it'll take for a Timeline to complete a single episode. This value can be defined using the TimeSpan syntax or it can use a predefined value, defined within the Duration struct and described in table 22.1.

Table 22.1 illustrates that you have two options when it comes to controlling the Duration of an animation. To control the playback speed of an animation, call on the SpeedRatio property.

The SpeedRatio property represents the throttle for a Timeline. By default, this double-precision value is set to 1.0. This value can be set to any positive double-precision value and act as a multiplier to the Duration property value. Figure 22.2 shows the Duration, SpeedRatio, and time values for a completed Timeline.

Figure 22.2. The effects of the SpeedRatio on a Timeline with a Duration of 10 seconds

As figure 22.2 illustrates, the SpeedRatio property can have a pretty significant impact on the Duration of a Timeline. These results show that any value less than 1 will slow down an animation. At the same time, any value greater than 1 will speed up the animation.

Besides adjusting the speed of an animation, you may need to repeat its performance. For this reason, there's a RepeatBehavior property.

The RepeatBehavior property is an interesting animal that may act differently than you're anticipating. This property enables you to specify how many times an animation should be played back-to-back. This property also enables you to specify how long the animation should run regardless of the Duration value—the animation will play back-to-back until the time specified in the RepeatBehavior property has elapsed. To get a further understanding of how this property works, examine figure 22.3.

Figure 22.3 illustrates the effects of the RepeatBehavior property in relation to an animation's Duration. The first three bars illustrate how to use the RepeatBehavior to specify the total number of times a Timeline should run. The last three bars show how to use the RepeatBehavior to specify a specific length of time for a Timeline.

As shown in the first three bars, you can append an x as the suffix to a positive, double-precision value. This suffix informs Silverlight that you want an animation to run a specific number of times. The total number of times is represented as the value before the x. If the RepeatBehavior is set to 2.0x, the animation will run two times; if the value is set to 5.0x, it'll run five times. These types of values can have a significant impact on your animations.

Figure 22.3. The effects of the RepeatBehavior on a Timeline with a Duration of 10 seconds

If the value before the x is greater than 1.0, you may notice a jerk between the iterations of the animation because, unless your animation ends with the same value as it started, it'll need to jump to the start to be reset. If the value before the x is less than 1.0, you'll notice that the animation will stop before the animation has completed because the RepeatBehavior takes precedence over the Duration property. This can have significant implications if you specify a time value as shown in the last three bars of figure 22.3.

By specifying a specific length of time for the RepeatBehavior, you're informing the Timeline to repeat until the specified time has elapsed. This length of time can be specified using the TimeSpan format. Or, you can specify the Forever value to make the Timeline run until you programmatically force the animation to stop. Either way, at times you may want a more cyclical animation. For these situations, you may want to consider the AutoReverse property.

The AutoReverse property enables you to automatically play a Timeline in reverse after it has played once forward. This boolean property is, by default, set to false. Changing this property value to true can enable you to deliver a throbbing effect— among other things. Note that changing this property to true can have residual effects on the overall playback of a Timeline.

By setting the AutoReverse property to true, the overall playback time of a Timeline may be doubled. When the AutoReverse property is true, a Timeline isn't deemed finished until it plays once forward and once backward. If you're specifying a number of iterations within the RepeatBehavior property, a single iteration will take twice as long.

Once an iteration has completed, you should have the ability to decide how it should behave.

When an animation reaches the end of a Timeline, it normally stays (or holds) at the end, but the FillBehavior property gives you the opportunity to determine what to do. When the end is reached, you can tell the playback what to do using one of the options provided by the FillBehavior enumerator. These options and their descriptions are shown in table 22.2.

You have two options: stay at the end or reset to the beginning. But the beginning of a Timeline isn't necessarily what it may seem. This beginning of a Timeline can be altered by the BeginTime property.

The BeginTime property represents when to start playing a Timeline. In reality, this property sort of behaves as an offset, which can be set using the familiar TimeSpan format. By default, the BeginTime property's value is set to null, which translates to 0. This setting is why animations begin playing immediately when told to do so. You can set this value to another TimeSpan value to provide an offset, as shown in this example:

<DoubleAnimation Storyboard.TargetName="myImage"
                 Storyboard.TargetProperty="Opacity"
                 From="0" To="1"
                 BeginTime="00:00:5" Duration="0:0:1" />

This shows an Image that fades in over the course of one second. Unlike the previous animations, this one won't start immediately. Instead, once the animation begins to play, it waits until the time specified within the BeginTime property has elapsed. Once this time period has elapsed, the image begins to fade into view. Because of this, you can assume the entire animation in this example takes six seconds to complete.

The BeginTime property may seem somewhat odd. It is sort of odd if you consider it only in regard to a single animation, but this property provides a significant amount of value when you have multiple animations working together. To make use of multiple animations, you must take advantage of the required Storyboard element.

The first approach for organizing a Storyboard involves defining it as a resource. A resource is an easy way to set aside a commonly used item for reuse. (We'll cover resources more in chapter 23.) This item—in our case, a Storyboard—can be defined as a resource by creating it within the Resources collection of a UIElement. This can be accomplished by either programmatically adding it through code, or creating it within XAML as shown in listing 22.7.

<Canvas x:Name="myCanvas">
  <Canvas.Resources>
    <Storyboard x:Key="myStoryboard">
      <DoubleAnimation Duration="00:00:01"
                       Storyboard.TargetName="myImage"
                       Storyboard.TargetProperty="Opacity"
                       From="1" To="0" />

    </Storyboard>
  </Canvas.Resources>
  <Image x:Name="myImage"
         Source="http://www.silverlightinaction.com/man.png" />
</Canvas>

This listing shows how easy it is to define a Storyboard as a resource in XAML. The definition of the Storyboard is placed within the Resources collection of the root Canvas. The root element of a Silverlight page is generally where you'll place your resources because it makes the resources accessible to all the elements within the page. Thankfully, the Resources collection can store as many or as few resources as you need.

Once a Storyboard is defined as a resource, it's your responsibility to start it. You must first programmatically retrieve it. This step involves retrieving the storyboard by key. The following example shows the Storyboard from listing 22.7 being retrieved from the resources collection, then programmatically started via the Begin method:

Storyboard myStoryboard = (Storyboard)(myCanvas.Resources["myStoryboard"]);
myStoryboard.Begin();

This illustrates how simple it is to programmatically start a Storyboard defined as a resource.

There are times when you know that a specific action should automatically start a Storyboard. For these situations, Silverlight provides an elegant shortcut that enables you to automatically start a Storyboard when a defined event occurs.

The second approach for defining a Storyboard involves setting it as an event handler. An EventTrigger is a special element that enables you to declaratively define a response for a specified event. When this event occurs, the EventTrigger automatically starts the defined Storyboard. To accomplish this, you follow a few simple steps.

First you decide which event you want to respond to. Currently, the only event supported within the EventTrigger is the Loaded event. To specify this event as the triggering event, you must identify the type of object responsible for the event. Once identified, you can set it, as well as the event, through the RoutedEvent property as shown in this example:

<EventTrigger RoutedEvent="Canvas.Loaded">
  <!-- Insert Actions here -->
</EventTrigger>

As this shows, the RoutedEvent property uses a syntax that resembles elementType-Name.eventName. The type name comes from the parent type. Generally, you'll be able to retrieve this type name from the attached property containing the trigger. This attached property is called Triggers, and it's available from all UIElement objects. If you were to expand on our previous code example, you should have something like this XAML fragment:

<Canvas.Triggers>
  <EventTrigger RoutedEvent="Canvas.Loaded">
    <!-- Insert Actions here -->
  </EventTrigger>
</Canvas.Triggers>

This example shows how the EventTrigger has been added to a Canvas. Significantly, this doesn't mean that the target of the Storyboard will be the Canvas. Instead, as discussed earlier, the target of the Storyboard is set within the Storyboard itself. To set the target of the Storyboard, you first define the Storyboard.

If you're defining a Storyboard within an EventTrigger, you must associate it with an action. Currently, Silverlight only provides one action called BeginStoryboard, which starts a Storyboard when called. You must use this action if you're creating an EventTrigger. To put all the pieces together, defining a Storyboard as a trigger would look like listing 22.8.

<Canvas Width="100" Height="100" Background="White">
  <Canvas.Triggers>
    <EventTrigger RoutedEvent="Canvas.Loaded">
      <BeginStoryboard>
        <Storyboard x:Name="myStoryboard">
          <DoubleAnimation Duration="00:00:01"
                           Storyboard.TargetName="myImage"
                           Storyboard.TargetProperty="Opacity"
                           From="0" To="1" />
        </Storyboard>
      </BeginStoryboard>
    </EventTrigger>
  </Canvas.Triggers>
  <Image x:Name="myImage"
         Source="http://www.silverlightinaction.com/man.png" />
</Canvas>

This example shows a Storyboard defined as a trigger. But the official Silverlight documentation included with the SDK recommends against using a trigger, as visual states (covered in chapter 23) and behaviors are often better ways to start the animation. Either way, the Storyboard provides a way to logically organize your animations.

These animations are all about changing a visual property over time. As you've seen, this process works in a linear fashion. To create even more dynamic visual effects, it's important to consider using a technique known as keyframing.

Linear interpolation constructs the most direct transition between two key frames. The linear descriptor is used because the change between two keyframes occurs at a constant, linear rate. Figure 22.6 shows an object moving between several points using linear interpolation.

Figure 22.6. How linear interpolation is determined. Note the straight lines between points.

The idea of using an animation that occurs at a constant, predictable rate at first seems appealing. But, as this figure shows, you can easily end up with a jerky or jagged animation. This jarring can leave users feeling like they're riding an old, wooden rollercoaster. This effect occurs because the transition between two linear keyframes occurs in distinct states. These stages may be desirable, but if they aren't, there's a way to create even smoother transitions thanks to spline interpolation.

Splines are generally used to create smooth, seamless transitions. These transitions occur by estimating the values as if they were generated along a Bézier curve. This curve represents the values to use within a time segment. To illustrate, figure 22.7 shows a curved interpolation.

If you compare this figure to figure 22.6, you can see how using splines allows you to create a much smoother transition between keyframes. Note that the line in this figure doesn't represent the path that the ball travels along. Instead, the line gives the illusion of varying speeds. These varying speeds are controlled through the KeySpline property.

The KeySpline property enables you to control the progress of an animation through two control points, which determine the curve that the values are interpolated along. By default, this curve resembles a straight line. To generate values along something other than a line, you must understand how the KeySpline relates values to points in time. This relationship, as well as the KeySpline syntax, is shown in figure 22.8.

Figure 22.7. An example using spline interpolation for approximation

Figure 22.8. The relationship between time and value as used by the KeySpline property.

This figure shows the default curve defined by the KeySpline property. The two control points used in this figure are specified as 0.0,0.0 1.0,1.0. These control points always follow a syntax that mimics x1,y1 x2,y2. In addition, each coordinate within each point is specified as a positive double-precision value between 0.0 and 1.0. Anything outside of this range will create a runtime error.

The first point defined within the KeySpline property determines how values will be generated along the first half of the curve. The second point defined within the KeySpline property determines how values will be created along the second half of the curve. Either way, if the y value is greater than the x value, the animation will run more quickly. Alternatively, if the x value is greater than the y value, the animation will run slower. Figure 22.9 shows sample curves along with their respective KeySpline values.

Figure 22.9. Sample time/value curves used by the KeySpline property

Figure 22.10. An example using discrete interpolation for approximation

The curves shown in this figure represent potential curves you can use for interpolating values. In reality, you'll need to play with these values until your keyframe animation feels right. Sometimes, an animation may feel right if the transitions are more discrete.

Occasionally, you may have to create an animation that jumps between values. These rifts seem counterintuitive within the realm of animation because animations are generally considered to be smooth. But, what if you were creating an animation that depicted a Whack-a-Mole game? In a Whack-a-Mole game, small critters appear at random from dark holes. This surprising effect can be effectively recreated using discrete interpolation.

When discrete interpolation is used, Silverlight generates sudden changes between two keyframes. These sudden changes make it appear as if the interpolation doesn't occur at all. That's because it doesn't! Figure 22.10 illuminates how the discrete method interpolates.

This illustration is difficult to make sense of. Everything seemingly occurs at random, just like Whack-a-Mole.

Although randomness has its place, you often need control over when a keyframe occurs. Luckily, there's is a property that allows you to do just that—KeyTime.

The KeyTime property of a KeyFrame represents the time at which the value specified within a KeyFrame will be reached. In a sense, the KeyTime sort of represents a bookmark within an animation. But, the position of this bookmark is completely dependent on the TimeSpan value you use.

By providing a TimeSpan value, you can specify the exact point in time when a KeyFrame should be reached. This point in time is relative to the beginning of the animation that the KeyFrame is defined within, so the order of the keyframe elements is irrelevant. But, this value still has to be assigned to the KeyTime property, as shown in listing 22.10. In addition, the example shows an illustration of how the animation would be rendered.

Example 22.10. Using a TimeSpan value to specify the KeyTime

This listing shows the typical approach for defining KeyFrame elements within an animation. The KeyTime value in each KeyFrame is set to a TimeSpan value. This approach provides a convenient and verbose way to perform an animation. This example shows how important the KeyTime property is in keyframe animations, which are the types of animations created by Expression Blend.

These animations have been interesting, but they've all lacked a certain amount of "pop" we've come to expect from modern applications. That's because they're not using any sort of easing functions with the keyframes. Let's fix that next.

EasingFunctionBase provides the structure of an easing function. It includes the EasingMode and its dependency property, as well as the Ease function, which is called by the animation system. The Ease function, in turn, calls EaseInCore, the function you provide.

This is where your easing code goes. You provide the implementation for EaseIn via the EaseInCore code, and the runtime will automatically infer EaseOut and EaseInOut from that. EaseOut will be the reverse of EaseIn, and EaseInOut will be the two together.

EaseInCore takes a double representing normalized time, and expects you to return the progress for that point in time. If you think of time as the x axis on a graph and progress as the y axis, you're taking in x as a parameter and returning y as the result.

A standard linear ease would return the value passed in. f(x) = x. Instantaneous movement would be f(x) = 1. No movement (ever) would be f(x) = 0. The interesting stuff happens when the result is between those numbers.

Listing 22.12 shows a randomizing ease. This uses the built-in Random object to provide a random value that approaches the final value. The end result is a stuttering animation that eventually gets to the right place.

public class RandomEase : EasingFunctionBase
{
  private Random _random = new Random();

  protected override double EaseInCore(double normalizedTime)
  {
    return normalizedTime / 2.0 +
           _random.Next(0, 100) / 100.0 * (normalizedTime / 2.0);
  }
}

<EasingDoubleKeyFrame.EasingFunction>
  <local:RandomEase EasingMode="EaseIn"/>
</EasingDoubleKeyFrame.EasingFunction>

To use this function, take the XAML from the ElasticEase demonstration and replace the two easing functions with the XAML fragment here. Be sure to map an XML namespace to the local application.

Easing functions really help liven up animation, providing a sometimes more organic but always more interesting way to move a value between two bounds. The built-in easing functions cover almost every need you'll have when animating in Silverlight. For those cases when the built-in functions aren't quite what you want, you can create your own easing functions as long as you an express the equation in code.

Easing functions were originally designed with Blend in mind. Designers love to be able to specify an easing function to use on a keyframe; they can do it right from the Blend UI. Another technology that came about due to Blend, this time from the Blend team itself, is the behavior. Behaviors are fascinating ways to add animation, code, or other reusable logic to your elements in XAML.

The FluidMoveBehavior helps get past abrupt layout changes. It listens to the layout system, and when it finds a layout change, it smoothly animates from the old value to the new value. This is extremely useful in panels such as wrap panels where resizing may move several elements around at once.

Listing 22.13 shows how to use the FluidMoveBehavior on a single element in the UI. We'll use the purple square example from the last section.

Example 22.13. Using the FluidMoveBehavior with an Element

This example shows how to smoothly move an element from one location to another. What would normally have been an abrupt change in location is now a four-second animation with an elastic easing function applied. These are the same easing functions we discussed earlier in the chapter.

Behind the scenes, this behavior builds an animation whenever layout-affecting properties (margins, top, left, size, and so forth) are changed, and uses that animation to move between the original layout value and the one specified.

Other behaviors attach to objects in similar ways. The parameters may change, but the approach is generally the same. In fact, we'll see that when we create our own behavior next.