Silverlight

I had read some blogs posts about the new smooth streaming capabilities for IIS 7.0, but I never actually experienced them myself. IIS Smooth Streaming is a technology that works with Silverlight in delivering a smooth video playback experience from Microsoft Internet Information Server in circumstances with varying network bandwidth.

It is really easy to try it out for yourself via http://www.iis.net/media/experiencesmoothstreaming

You get some controls to play with to artificially throttle the bandwidth available to Silverlight for downloading the video stream. If you throttle it down you can see how the stream smoothly switches to a lower bitrate version of the video without too much glitches in the playback experience. If you give Silverlight full bandwidth again, the bitrate gradually climbs up till you get real HD quality again (assuming your maximum bandwidth allows for that). A picture says more than a thousand words:

Experience Smooth Streaming  The Official Microsoft IIS Site

It also works with the Linux variant of Silverlight called Moonlight. Check out Miguel de Icaza’s blog for that.

1 Comment

For the last week, I have been in love with Photosynth. It was a tech preview in view-only mode for quite a while, but now we finally released it to the masses.

I've created three synths from existing pictures, i.e., from pictures I took without having Photosynth in mind. These are my first experiments:

  Photosynth (Build 10683) - Sunset Amsterdam

But these ones are much better:

Photosynth is a prime example of the execution on our Software + Services vision. It combines the best of the web with local computing power (on Windows).

Go create!

PS: I have a 40 Megapixel picture of Mount Rainier stitched from the same pictures as above. For the stitching I used Windows Live Photo Gallery. You can view it using Silverlight DeepZoom technology.

1 Comment

Some people use hyperbole to refer to the disclosure of Silverlight and CoreCLR by Microsoft at MIX07. April 30, 2007 has been called the day that will be remembered as the day that Microsoft "rebooted the web".

This might be true in more than one way. I was just reading the Silverlight SDK and was struck by a feeling of deja-vu:

<TextBlock FontFamily="Arial" Width="400" Text="Sample text formatting runs">
  <LineBreak/> 
  <Run Foreground="Maroon" FontFamily="Courier New" FontSize="24">Courier New 24</Run>
  <LineBreak/>
  <Run Foreground="Teal" FontFamily="Times New Roman" FontSize="18" FontStyle="Italic">Times New Roman Italic 18</Run>
  <LineBreak/>
  <Run Foreground="SteelBlue" FontFamily="Verdana" FontSize="14" FontWeight="Bold">Verdana Bold 14</Run>
</TextBlock>

Doesn't it feel like FONT tags all over again to you too?

This is not revolutionizing the web, this is indeed rebooting the web. Just after text on the web has been semantically liberated from FONT and TABLE tags by judicious use of CSS, we are going back to the future...

PS: Although there is extremely tight coupling between text and layout in this piece of XAML, it is still a much better situation than text locked up in .swf files. At least it is indexable by search engines. Hopefully, Microsoft is just going after the Flash market and doesn't lure us into putting all text inside Silverlight controls leaving the (X)HTML page as just an otherwise empty shell around such controls.

PS2: Here is another commentary by someone who sees some downsides to this new "rich" web as well.

WPF comes with great support for animation using XAML without needing to code this in for example C#. With Silverlight (fka "WPF/E") you can also do animations from XAML.

If you want to perform custom animations in code that you can't do using XAML, you need timers. In the full blown WPF you have several options, e.g., System.Threading.Timer, System.Timers.Timer and System.Windows.Forms.Timer.

You normally provide a callback that gets called when the timer elapses from a background thread. Properties on WPF objects can only be set from the foreground thread, so you have to queue a call on the UI thread to perform the actual animation. You can do that by calling the Invoke or BeginInvoke method on the System.Windows.Threading.Dispatcher class. You can access the correct Dispatcher instance to use through the Dispatcher property on the UI element (*).

Another option in WPF is to use the Rendering event of a CompositionTarget instance. In that case you get called when WPF is ready to render a frame. The frame rate depends on CPU speed, GPU performance, graphics complexity and other factors, so it fluctuates. This means that the interval after which you get called also fluctuates. However this is great for some scenarios.

In the current Silverlight 1.1 alpha your options are more limited. The CoreCLR libraries do have a System.Threading.Timer, but there is no Dispatcher class to delegate work to the UI thread. So it is useless for doing custom animation. In the source of the Monotone sample by Lutz Roeder I found there is an HtmlTimer class in Silverlight 1.1. This class is undocumented and marked obsolete. Visual Studio shows a warning after compilation:

'System.Windows.Browser.HtmlTimer' is obsolete: 'This is not a high resolution timer and is not suitable for short-interval animations. A new timer type will be available in a future release.

Lutz shows how to use an HtmlTimer in his sample. HtmlTimer has a Tick event. Any event handler that you wire-up to that event gets called from the UI thread. So that solves the problem for the time being.

When I tried to Google for more info on HtmlTimer, all I found was this blog post by Mike Taulty which mentions this class in passing.

(*) In fact any .NET class that derives from DispatcherObject has a Dispatcher property.

1 Comment

If you haven't heard the news yet, you must be living under a rock 😉 There is a new CLR in town. Silverlight (fka "WPF/E") 1.1 comes with its own CLR. And the best news is that it runs both on the Mac and the PC.

Go check it out at silverlight.net.

One of the greatest achievements is that the download is a mere 4 MB. If you have a reasonably fast Internet connection you can download and install it in under a minute. Try that with .NET 3.0! That will take at least an order of magnitude longer to install.

Before the announcment at MIX07, I wasn't sure if Microsoft would be able to pull this off. They have certainly gone beyond my expectations.

This is what the Silverlight directory looks like after the install:

 

It shows you this CLR is completely separate from the standard CLR 2.0 runtime and has no dependency on it. This CLR has 2.1.x.x as version number. It has no Global Assembly Cache (GAC). You can see that support for dynamic languages like Python and JScript is included. Support for Ruby is in the works.

Go listen to the Channel 9 interview with Scott Guthrie if you want to know how Microsoft succeeded in trimming down the CLR 2.0 and the Base Class Libraries to this size.

The Silverlight .NET assemblies have the same format as standard .NET assemblies, so you can view them using Reflector. The type system is the same, so Silverlight supports generics. It will also support C# 3.0, VB 9.0 and LINQ.

These are exciting times for the .NET world. The reach of .NET has been substantially increased. Not just because the few percent of Mac users can run .NET applications now, but because it is such an easy deployment for Firefox users on the PC. And soon for Opera users as well.

1 Comment

Microsoft has announced that the little cross-platform, cross-browser cousin of Windows Presentation Foundation will be called Silverlight. This technology which was first announced at PDC05 was codenamed "WPF/E".


Tim Sneath has the best list so far of the features and power of this "Flash killer" technology. Microsoft doesn't ever call Silverlight a Flash killer, but the overlap in feature set is so large, that it cannot be viewed as anything other than a direct Flash competitor.


However, I do believe that Silverlight leapfrogs Flash in a couple of ways. The programmability and ease of use is better than Flash. You can build Silverlight sites using just Notepad if you want. The direct integration of the Silverlight DOM (Document Object Model) with JavaScript in the browser and the ability to create Silverlight UI elements on the fly with the createFromXaml method is a killer feature.


Tim Sneath mentions a secret number 10 feature on his list:



"Ah... #10. I can't reveal this yet - there's a big surprise up our collective corporate sleeve that will be announced at MIX. I hate to hold back on you, but anticipation is part of the pleasure, as my mother used to tell me as a child when I was waiting impatiently for Christmas to come!"


Could this be the .NET programmability that was previously speculated about? Soma spills some more details in his announcement:



"As I mentioned, this Silverlight announcement at NAB is only part of the story, the rest will be unveiled at MIX including details about how Silverlight is a core component of Microsoft’s broader .NET platform."


I commented previously on Robert McLaws' blog that I didn't think that Microsoft wasn't going to release a lightweight crossplatform CLR for Silverlight programmability. But I also speculated that Microsoft was working on a bigger crossplatform CLR based on the .NET Compact Framework.


What I am pretty sure about, is that Microsoft will announce ASP.NET controls that will allow you to very easily integrate Silverlight on your web pages and to expose dynamic data as XAML to Silverlight controls. I.e., AJAX on steroids UI-wise.


Adding ASP.NET to the mix shows that there is no direct need for a CLR on the client in order to enable C# or VB.NET programmability: coding in C#, compiling to IL and converting that IL to JavaScript on the fly! Prototype efforts by Nikhil Kothari with Script# show that this is quite possible. Check out Nikhil's example.