No one needs more than 6 MB of Silverlight

1/4/2012 By Marco Kesseler 0 comments

How small should Silverlight be?

I am not talking about market share, nor am I comparing it to HTML5. No: how small should it be compared to its big brother WPF?

If you start porting existing WPF code to Silverlight, you will soon discover that quite a bit is missing. MSDN does not help here. It does list some differences, but it does not say anything about the issues below.

First of all, Silverlight lacks method overloads. These are often easy to solve, but as we like to share our code as much as possible, we now have to add some comments warning against using the old overloads, as any non-suspecting programmer might easily break things again when working on non-Silverlight projects that share the same code. Luckily it is often possible to use extension methods to add the missing overloads.

Other easy fixes include the lack of collections like (the non-generic) ArrayList or HashTable. Then there are missing parts that have an “existing” alternative. In WPF there are two ways in which graphics can be constructed. It is possible to “draw” in a constructive/declarative way by adding graphical elements as Children to other elements. But it is also possible to draw in a more imperative way using a DrawingContext. You will have to rewrite your code if you used the latter, because Silverlight only supports the former (yes, we used DrawingContext, because it resembles GDI+ more, which is were we came from...).

There are also missing parts that have a “new” alternative. There is no XmlNode. You will have to use the Linq variant XNode. And XElement, and XAttribute, and XDocument, and etc. So bascically all the old functionality is there, but you “just” need to use the new classes. If you have a lot of code, the best way is to recreate your own “Xml” classes and map all functionality onto the Linq “X” variants.

Cloning is also (largely?) missing. You will have to implement it if you need it. And you probably will, because sharing Graphical elements in a visual tree will lead to exceptions. It boggles the mind why someone decided to omit cloning without tackling the sharing exceptions in the visual tree.

And then there is missing functionality for which there is no alternative. At one point, we needed to take the intersection of two geometries in Silverlight, and we found no way to do it. Of course we encountered this after doing all of the above. It never occurred to me that something like this would not exist in Silverlight. Some suggested using a geometry group, but these only provide unions, not intersections. It almost proved to be a show-stopper.

But we were lucky: we only needed the intersection of two regions for clipping. It turned out that one can put a canvas with a particular clipping geometry an use it inside another canvas with another clipping geometry. And if you then draw inside the inner canvas, all graphics get clipped against both, which is effectively the same as clipping against the intersection of both geometries.

I am now left wondering whether Microsoft actually foresaw this use of nested canvases, and decided that geometry intersection was therefore not required, or whether this was just an accidental omission.

What is it with Silverlight and being small? I suspect that many programmers write “glue” code in order to port existing code to Silverlight. This all adds up to the size of their own apps, which have to be downloaded over and over again. It seems far more sensible if Microsoft were to write this glue code once and put it in Silverlight itself. I mean: what does it matter if the Silverlight installer is 6 MB or 30?

I suspect that only programmers care. Praising the small size of Silverlight is like saying that 640 KB should be enough for anybody in a time that half the world is busy downloading movies over the internet.