Animation! And more animation! We sure do seem to love animation here at Switch On The Code - and really, I have no idea why. But as long as we keep coming up with cool concepts that deal with animation, we will continue to write about them. Today we are going to take a look at something a little bit weird - we are going to animate HTML elements using Silverlight. Thats right, you read that correctly - HTML elements, the stuff you would normally animate with some plain old javascript - perhaps even the Generic Animation javascript code. Why would you want to do this? I don't have any good reasons at the moment. But it does show off some of the capabilities of silverlight, and that is a good enough reason to write about it.

One thing to note before we get started - you will need the Silverlight 1.1 Alpha Refresh in order for the examples on this page to work. If you don't have it installed, you probably won't see any notification of that fact. This is because, unlike most silverlight apps, the silverlight on this page has no display - so there is no place for the usual "Get Silverlight" image and link to appear. So if the examples on this page fail to work, I would suggest checking out some of our other silverlight tutorials to make sure that your silverlight 1.1 install is working.

So below we have the classic animation example that we use here at Switch On The Code. This time, however, the "Go!" button is not hooked to a javascript function, it is hooked to an function in the silverlight code-behind. And if you set some values in the text boxes and click "Go!", silverlight will move and resize the red box to the values given in the given amount of time.

New X Pos:		New Y Pos:
New Width:		New Height:
Time (Millisec)

Done playing? If so, we have some code here you might be interested in. I'm not going to explain all the code in extreme detail, because parts of it (especially the math) are extremely similar or identical to the javascript code in the Generic Animation tutorial - so if you haven't read that tutorial, I highly suggest it. For the parts of this code that are different, rest assured, there will be in-depth explanation.

The collapsed version of the AnimationObject is very similar to the javascript version, but there are a couple of added variables and functions:


So lets walk through this, explaining each function as we go. First we have the constructor, which takes in an HtmlElement and initializes the AnimationObject. The code for it looks like the following:


So what is this _WorkTimer and _UITimer business? The javascript animation code did not have anything like this. Well, this is the equivalent way of doing a setTimeout in javascript, with an added twist. Because silverlight uses the .NET framework, we actually have access to multiple threads. So in this animation code, we take advantage of this fact by having two timers - the _WorkTimer and the _UITimer. The _WorkTimer does all the math and figures out the new position for the element, while the _UITimer applies that position to the element. The _UITimer runs on the main silverlight thread (sort of equivalent to the javascript setInterval function, while the _WorkTimer will run on a separate thread.

One thing to remember, only the main silverlight thread can update xaml or dom elements on the actual page. This means that if we tried to do any actual user interface work with the _WorkTimer, silverlight would throw an exception. Also, the _UITimer is an instance of HtmlTimer, which will probably be replaced with a better timer function (or the ability to invoke across threads) in the final Silverlight 1.1 release. But for now, it is the only way to update the user interface on any sort of interval.

We will talk about what these two timers are actually hooked to later on, when we get to those functions. Now on to the next function:


Almost identical to the AddFrame function in the javascript code. But now let's take a look at the AnimationFrame object, which has changed a little bit since the javascript version:


The form is almost identical to the AnimationFrame that we had in the javascript code - but some of the content is slightly different due to how C# accesses html element properties, and C# syntactical differences. The code here also takes advantage of the possibility of multiple constructors - something you can't do in javascript without a good bit of difficulty. So the main difference is the added function SetToElement, which takes an html element and sets the values in the frame to the values from that element. Sadly, we have to a bit more work here in C# to get the values out (which is why I encapsulated it into a function). Unlike javascript, the integer parsing is very finicky - so we have to get rid of the 'px' that is at the end of the style properties.

Onto the next function, SetCallback, which is again almost identical to the version in the javascript code:


The only special thing here is the NoArgDelegate type, which needs to be defined somewhere in the code as a function that takes no arguments and returns nothing:


Next function to look at is ClearFrames:


Since our AnimationFrame object can now take in an HtmlElement as an argument to the constructor, this cleans up the code a little bit as compared to the javascript version. But other than that, they are identical.

The variables _Running, _CurrentFI, _PrevDir, and _CurrentData mean the same things as they do in the javascript animation code. Just as a refresher, for the _Running variable 0 means stopped, -1 means running backward, and 1 means running forward.

The next two functions are ResetToStart and ResetToEnd:


These two functions are again identical to the javascript code. I know, not particularly interesting. But don't worry, we will be getting to the interesting code soon.

Next we have the Stop function, which is a little different from the javascript animation version:


Here, the difference is that instead of clearing the javascript timeout, we have to stop the _WorkTimer. We do this by setting its "dueTime" (the amount of time until the next tick of the timer) to infinity. The _UITimer will actually stop on its own - we will see how that works later.

Now onto the meat of the code - we have the function RunForward next:


The flow of the code is identical to the javascript code, but there are a couple differences. First, to get the current time in ticks, we use Environment.TickCount (as opposed to new Date().getTime() in javascript). The fact that we have the new method SetToElement on the AnimationFrame object cleans up a little bit of the code in the middle. And finally, instead of just calling animate at the end of the function, we start the two timers. For the _WorkTimer we change its "dueTime" to 0, which means start firing immediately, and with the _UITimer, we just enable it.

The RunBackward function is next:


Again, very similar to the javascript RunBackward function, except for the same changes that we made to the RunForward method.

We have finally reached the function where all the action happens - animate:


The math and code flow again are identical to the javascript animate function - but there are some other significant differences. First, the animate function now takes an argument, although the argument is meaningless. This is because this function is attached to the _WorkTimer, and the Timer class expects the callback function to have that method signature. The next major change is that whenever we are writing to the _CurrentData variable, we surround it with a lock. This is because the _UITimer could tick at any point during this function - so we never want the _UITimer to try and read _CurrentData while the code in animate is writing to it.

This leads us into another difference - we never actually apply the results to the html element. This thread can't actually do that, we just calculate them and leave them in the _CurrentData variable. It is the job of the function attached to the _UITimer to actually update the element.

The other significant difference is how the callback function is called when the animation finishes. Again, since this function is running on a seperate thread, we don't want to call the callback directly. So instead, when the animation is complete, we attach the function CallbackHit to the _UITimer - which means that the next time the _UITimer ticks after that point, CallbackHit will be called and it will be running on the main silverlight thread (instead of the current timer thread).

Since we are talking about CallbackHit lets take a look at it:


Pretty simple - as soon as it gets hit, it detaches itself from the _UITimer so it doesn't get hit again, and then calls the callback if one exists.

The final major function is the one always attached to the _UITimer - UITimer_Tick:


It is also pretty simple - it locks _CurrentData (so the animate function can't write to it), applies it to the element, and then in the animation is no longer running it turns off the timer.

And of course, since this is C#, we now have to worry about disposing things - in this case the timers. So we have the dispose function for when we are done with the animation object:


And that is all the code! Below is it all together in one chunk, and then below that we go through how to actually use it:


As usual, here is our fun animation example, the same one we used at the end of the javascript animation tutorial.




So how do we actually get this in silverlight with the code we just created? Well, lets take a look:


Again, almost exactly the same as the javascript, with the exception of the syntax. Even setting up the callbacks so that the animation runs forever is the same.

Hope you enjoyed learning about how to do html element animation using silverlight! Look for an article soon with some benchmarks on which method performs better (javascript or silverlight), as well as some other performance comparisons between silverlight and just plain old javascript.