fluxcapacity

As it stands, I don't see Silverlight as a Flash-killer.  Flash is mature and still actively developed; Adobe recently opened up Flex (Flash development framework) as an open source project - perhaps intended to keep an edge over Silverlight in developers' minds.

That said, I want to make the claim that Silverlight 1.1 has the capability to outshine Flash/Flex for a certain class of CPU-intensive web applications, of which Fluxify is an example.  For starters, you need to check out Alexey Gavrilov's BubbleMark.  The site compares Flash, Silverlight, and a bunch of different web platforms in terms of their performance at displaying some bouncing bubbles.

Sure, bouncing bubbles are probably not the most representative of web applications in general, but Alexey did an incredible job of touching seemingly every platform.  On my machine, the optimized Flex version of BubbleMark achieves 64 fps, the Silverlight+Javascript version slogs through at similar speeds, whereas the Silverlight+CLR equivalent chimes in around 270 fps, or 4.2 times faster!  This faster CLR version requires Silverlight 1.1, and is written in C# instead of Javascript.  Thus, I assume that Silverlight's CLR engine is a lot faster (4.2X) than the Flex runtime, and this is the basis for the claim. 

To dig deeper, let's compare three numbers: 371, 3827, and 907 (kilobits per second).

371: This is a recent measure of the median internet upload speed in the USA.

3827: This is the effective speed at which Fluxify (w/Silverlight CLR) can upload a JPEG, including all client-side processing. Of course we're not uploading the full-size files, but for many applications (such as emailing photos), doing so is unnecessary.

907: This is the effective speed at which a Flash/Flex application could do the same thing, assuming the BubbleMark speed comparison holds, and that you can avoid uploading the image first for this example as well. 

To make this more visceral, let's assume a 12 megapixel JPEG, and convert these speeds into time:

79 seconds @ 371 kbps - Full upload - no client-side processing
32 seconds @ 907 kbps - Flash process + upload
7.7 seconds @ 3827 kbps - Silverlight process + upload

At this point, Flash developers will quickly point out a flaw in my analysis.  As it turns out, Flash Player currently does not allow access to file streams before upload, so the best Flash image editors out there, such as rsizr, are still at the mercy of upload speeds (that is, 79 seconds for our example).  This brings us back to the claim: Silverlight has an advantage in this type of application.  Is it significant enough to prompt developers to adopt it for applications in this niche?  Maybe... but let's look at one more number:

8343: This is the speed at which Fluxify can process and display a JPEG.  For our 12 megapixel example, that's 3.5 seconds.  This figure also applies if we want to save the file locally (for example, if you wanted to attach photos to an email manually, or to upload them manually to another site). Wait, except, you can't do this yet, which brings me to Silverlight's missing piece: the SaveFileDialog.

The SaveFileDialog?

SaveFileDialog sfd = new SaveFileDialog() { 
    Title = "Select a location to save your photo"; }

if( sfd.ShowDialog() == DialogResult.OK )
{
    using (Stream jpgFileStream = sfd.OpenFile())
    {
        /* you wish. */
    }
}

With Silverlight today, there's an OpenFileDialog, which lets us open and process files within the context of our application. We can do whatever we want with the bytes inside this file, and then we have a few options:

1. Display the data

• We can display arbitrary text data onscreen. We can even display images, but in a very non-ideal way by rendering them manually  (Skip to the bottom for notes regarding this limitation.)

2. Upload the data

• No problem. We just use the BrowserHttpWebRequest and call your server.

3. Store the data locally

• We can?! Well, sorta...but only in the IsolatedStore (1MB cap). This means the file is shoved deep within the user's profile:

i.e. %userprofile%/AppData/Local/IsolatedStorage/***
In my case, those stars equate to:

ynckhjp5.2bb/lw1djvut.lfx/Url.wj54i ... /AppFiles
 

Got that? :) Since we can't refer the user to this folder directly, it can't really supplement the missing SaveFileDialog. 

Problem:  A SaveFileDialog doesn't exist, so we can't store the data anywhere useful for the user.  That's why Fluxify doesn't support saving your JPEGs after resize.  In other words, you're stuck at 3827 kbps.  So, where do we go from here?

Solution: Wait for version 2.0?

If this functionality doesn't pop up in Silverlight 1.1, it will give Flash/Flex a chance to bring their runtime up to par with Silverlight's CoreCLR.  Flash developers have requested pre-upload file stream access, and other FileReference enhancements are popping up in Flash 9 Update 3, which will be released tomorrow.  While Flash Player doesn't allow it, there's currently an Adobe AIR trick in use which lets you simulate a "Save File" dialog by faking a download().  Improvements are on the way, and Flash developers can migrate existing applications to do more intensive work client-side.  New developers will decide on Flash/Flex because of its maturity, and timeframe uncertainty on a Go-live license for Silverlight.  Client-side data processing is of course only one of many real-world considerations.  I'm overestimating the cascade influence of this single feature, but I do think developers really care. 

Solution: ActiveX control?

Of course we could make a little browser plugin to allow this, and prompt our users to install some EXE.  Unfortunately, this negates the advantage of using a web platform.

Solution: Google Gears?

Google Gears, a cross-platform tool giving web applications an offline store, can help us get around this problem with its LocalServer functionality -- a browser plugin which intercepts all web requests and potentially redirects them to the local application's data store.  SilverGears is proof of concept showing integration between Silverlight and Gears.  Of course, if you haven't installed Gears yet (I hadn't until today), this is another EXE download.  Gears also has a relational database client-side, which is a big plus for query-bound applications (say, an email client).

If anyone has insight into this problem, or this niche in general, we're very curious to hear.

Notes on image display: Silverlight actually has another missing piece, which is the ability to manipulate images and sounds at a raw level, so that we can perceive results without round-tripping them to the server.  At the very least, we should be able to instantiate these objects from byte arrays.  You can do this in Flash with the BitmapData class.  For Silverlight, one potential trick is to use the browser to display images: Firefox supports the data:uri spec for images.  If you're running Firefox, try Shift-clicking on a resized photo in Fluxify for a demonstration.