Working With Silverlight: My Impressions

A Flash developer makes games in Silverlight, and lives to tell the tale.
2008-03-15

I've been working on some game projects using the Silverlight technology. As such, its been very interesting to try to do something extremely complex with such a fluid technology. I look at some of the things that people have been doing with it, and its pretty cool. I'm truly impressed by the ingenuity of a lot of the developers out there. The Hard Rock Memoribilia site is a fun, engaging experience.

I have had numerous long discussions with various people about Silverlight. Mainly because they are very keen to work with the technology, and I'm not. After working on three projects I am not looking forward to working on the next. But I know that things will be improving and I want to be a part of that change.

I have been a flurry of mixed signals because I'm not very good at saying what I really want to say, and trying to be optimistic regarding the outcome. Overall the outcome for Silverlight will be pretty positive. I think that the strength of programming and sheer power that Microsoft brings to the table will make sure that Silverlight takes hold. But in its current form I have a hard time getting the work done.

So lets break this article up into a couple subsections:

• Perception vs. Reality
• What Works
• What Doesn't
• Blend
• Huge Systemic Flaws (HSF)

Perception vs. Reality

Its hard to really get a sense of what's going on with Silverlight, when there is such a whirlpool of spin surrounding it. The spin I find the most is the expectation of what Silverlight will be able to do, and what it can do right now. Its often 'you'll be able to do that soon'. Why should I work in a system that can do it soon when I can do it right now with Flash/Flex?

Is Silverlight a viable platform for Rich Internet Application development? Well, not yet. But so many people want it to be. Not just the Microsofties, but many developers too. Why? Because there are so many developers out there working with Microsoft products already that they want to be able to do what they do, but deploy for the web. Sure, ASP.NET is cool...but AJAX is a pain, and it doesn't have the whiz-bang of Flash, or some of the more useful features of Flash: audio, video, upload, etc.

Enough people believe in Silverlight that they're just going to 'will' it into existence. Its going to, at some point, have all the features it says its going to have, right? I'd have to say that Jesse Warden guessed right: the excitement is really towards WPF, not Silverlight. And the hope is that most of that WPF goodness will be directly transferrable to Silverlight.

What Works

There are some things that, right now, Silverlight does very well. It plays very well with Video, and its performance in some areas is fantastic. In Silverlight 2.0 you now have LINQ so I hear that working with XML is much easier.

Video - A lot of the current real-world apps are video players. So if you want to build a video player, Silverlight is for you. Microsoft also seems to understand the needs of broadcasters more than Adobe. Silverlight's video features escalate to really handle Big Video well.

Deep Zoom - This is a really nice feature. There is basically a very smooth Seadragon style image zoom effect. The Harley-Davidson site has something like this.

Managed Code - Managed code is executed not by the operating system, but by a virtual machine. This is a great way to abstract your code's compilation, and then execute it on many different platforms. Interestingly up until now, that just meant Windows machines. So potentially any platform that has a Common Language Runtime will be able to display Silverlight content, a necessity for today's varying environments.

LINQ - A great improvement in parsing text, and in general just a cool feature.

Smooth Frame Rates - The renderer can be very fast at rendering. The performance bottlenecks are in different places than Flash. It may take some getting used to, but its nice to see the player Just Render at a good clip and not have to worry about frame rate.

What Doesn't

Text Display - There is an option for custom font embedding, but I have not really used it. We had problems with getting text wrapping working, but are unsure of whether it was us or the framework. Regardless, working with text is more mystery meat than it needs to be. This is one of the areas where things have been coming along, and I should expect leaps and bounds to be made because it is an integral part of an RIA experience.

Instantiation - Silverlight doesn't seem to have an idea of an original 'prototype' copy of any control. Controls must have XAML added to it via the LoadComponent() function on each instantiation. This is a huge performance hit, as all objects created on the screen must be converted from a string-based representation to code everytime they are made.

This means that if you, say, have a 20x20 grid of tiles on a game board that are all identical, it will parse the XAML's XML 400 times to create those components.

The expected behavior in this system, for me, would be to retrieve some sort of 'master' class or 'factory' object that you could then use to create your actual xaml instances. For example:

ControlFactory cf = ControlFactory.getInstance();
cf.loadXAML("myControl.xaml");
cf.loadXAML("myControl2.xaml");

cl.createNewControl( this, "myControl.xaml");

The performance hit is very significant when generating lots of XAML. Something many applications won't have a problem with, but a wall that we ran into on one project.

Sound - Well, I must admit that I haven't done much with sound, and so I've gone ahead and asked our sound programmer his thoughts. Overall, there are bugs that make sound playback very problematic for effects. Looping sound isn't really feasible too, its not seamless. Fading in and out could be simpler. So overall, don't expect any sound apps on Silverlight anytime soon.

Keyboard Input - Keyboard input has consistency problems. We built one project with the Control key in mind, finding out at the end of our dev cycle that, well, you can't get an event off it on Macintosh. According to the MSDN docs, it should be the 'Command' key on Mac, but no such luck.

Partial Classes - There is a major bug if your controls inherit a subclass of UserControl, instead of the partial recognising this, it will instead inherit from UserControl. You can manually update this file, but every time you change your xaml, Visual Studio will overwrite your change. We got around this problem by using BeyondCompare to diff the files, and then manually fixing every...single...file.

Your best bet is to avoid inheriting from UserControl unless it really makes sense to, and also if you are not updating your XAML often.

Mac Performance - We were very dismayed to find that one of our projects doesn't really run that well on Macs with not-so-hot graphics cards. Ironically, I get a better frame rate in my virtual copy of Windows XP on Mac, than on OS X.

Blend - I find that Expression Blend is a very hard program to work in. From a designer perspective, its hard to understand the methodology and workflow of Blend. It doesn't import from any program except Design. There are some important features missing, and is somewhat unstable. The main problems within Blend though, are a product of the HSFs.

Huge Systemic Flaws

I'm writing this not to bash or to praise, but to help illustrate the current landscape of Silverlight development. More importantly, I hope that key people will listen to what I have to say, and make Silverlight a better product. So what do I mean by Huge Systemic Flaw? The following items are, in a sense, deal breakers. Because these problems are so deeply ingrained, via bureaucracy/methodology/whatever, that it will be extremely hard to change them, but not doing so is so costly that it could mean huge failures, lost opportunities and unrealised markets.

Get Rid of XAML - XAML, to WPF developers, is probably an amazing new way to develop really pretty applications. It must be like night and day between the old days of grid-based layouts and layout managers. Its a great step forward, and one of the best ways to make apps, period.

That doesn't mean its small and efficient. The path data in it is huge. And Expression Design wants to name everything on import, meaning the XML is even larger. What's worse is that there's nowhere to store meta-data except in the XAML. So if you needed that, it'd get even bigger. We once had a 3.5MB XAML file. After some time-consuming optimization we got it down to 700KB, hardly stellar. The problem in this particular instance is two-fold:

• The designer working on the document imported artwork without any realization of how big it was. He was a senior designer with good technical chops. If a quality designer can create such a huge problem, what happens with more inexperienced team members?
• The idea behind an Application Markup Language is that it should Mark Up Applications, not define content. But currently that is how Silverlight defines all vector content. Hence, huge filesizes.

In WPF there is BAML, which is a binary representation of xaml. This may be the way to go. Perhaps you have a work file, and that contains all of your baml/xaml/meta-data/resources, and spits out what you need, such as baml, or even .xap. I like the way 3DSMax has plug-in 'renderers' and I think a similar format would be very beneficial to Silverlight.

Create a Work File Format - Let's pretend that Blend introduced the concept of guide layers into the program. Where would that information go? Into the already huge and overly bloated XML? This metadata doesn't belong there, and could even potentially contain data I don't want others to see. I've seen designers put passwords into guide layers in flash. What if some unknowing designer published a similar xaml document onto the web?

Currently there is little metadata associated with XAML content. With the new version they've added a new xml namespace that defines metadata. My expectation is that meta-data is going to play a bigger and bigger part of Silverlight development. So why store it in the XAML? Why not create a compact, binary format that contains all your resources and metadata, and can export to whatever format you're after? This would also negate the huge performance penalty of keeping the xml representation up to date, as you would simply output to your preferred format.

Frame-by-Frame animation support - Currently storyboards are developed in a time-based fashion. I think this is a great format, and by default, the best way of animating most things in XAML. But what if I want to use an image sequence? Or a vector frame-based animation? The work involved is somewhat intensive, and not ideal. While a time-based solution can be better than frame-based, it is not *inclusive* of frame based animation, while frame-based animation *is* inclusive of time-based animation. This is another argument for a work file, so that the timeline production can be abstracted from the execution.

Better Object Taxonomy/Recursion - I probably could find a better way to say this, but I don't really know how to. This is a very Flash feature, and the reason why it put the nail in the coffin of Director. It is the 'killer' feature of Flash. The idea is to easily create a recursive Class->Instance relationship between visual objects, and be able to effortlessly embed them semi-recursively into each other.

Currently the work involved with embedding UserControls into each other isn't very effortless. And the ability to preview the results requires a full compile. Yes, I know you can get a visual preview, but you cannot see the animation in action. But really the issue is less with preview but workflow.

In Summary

Overall the progress of Silverlight has been great. The quality of work continues to improve, but the future is uncertain. I can see it being a clear contender for RIA development if it continues to port WPF over. Its video abilities are the most intriguing. Things are more murky when it comes to multimedia, entertainment and advertising. Application development is the realm of WPF and developers. Interactive is the realm of Blend. Much work needs to happen to get Blend to a usable state, so I expect the near future of Silverlight to be more application/video based, and once those features have solidified, we'll see more happen in terms of games, advertising, and 'rich' experiences.