WPF architect Greg Schechter was written a series of articles on the new hardware accelerated shaders recently released in beta form, as part of .NET 3.5 SP1 beta. This article includes some sample code that was enough to get me started down the path of writing a very simple shader effect - I've dubbed it "watery" but it's more just "wavy".
In this example the "waviness" of the effect is bound to the value of the slider at the bottom of the screen. One thing that I thought was very nicely done by the WPF team was the mechanism for passing parameters from WPF into the HLSL code using an attached property declaration like this:
public static readonly DependencyProperty WavinessProperty =
DependencyProperty.Register("Waviness", typeof(double), typeof(WaterEffect), new UIPropertyMetadata(0d, PixelShaderConstantCallback(0)));
The last part is the most important bit, which wires up the dependency property that has been defined in our C# WPF code to a constant in the [very crude] pixel shader HLSL code:
sampler2D implicitInput : register(s0);
float waviness : register(C0);
float4 main( float2 Tex : TEXCOORD ) : COLOR
{
float4 Color;
Tex.y = Tex.y + (sin(Tex.x * waviness)* 0.01);
Color = tex2D( implicitInput, Tex.xy);
return Color;
}
At the moment this sample is very much alpha, and sometimes does some very weird things to the contents of the window. Regardless I'm very impressed at how approachable the WPF team have made this stuff.
I ran into this issue when IE8 was first released and it doesn't seem to have gotten much visibility elsewhere. IE8 Beta 1 breaks image downloads for WPF applications when the image has a web uri. From the stack trace this seems to be caused by wininet.dll not returning the internet cache folder correctly. A typical call stack for the error message might look something like this (when the uri specified is a http uri, I haven't checked FTP)
A first chance exception of type 'System.ArgumentException' occurred in PresentationCore.dll
System.ArgumentException: Value does not fall within the expected range.
at System.Runtime.InteropServices.Marshal.ThrowExceptionForHRInternal(Int32 errorCode, IntPtr errorInfo)
at MS.Win32.WinInet.get_InternetCacheFolder()
at System.Windows.Media.Imaging.BitmapDownload.BeginDownload(BitmapDecoder decoder, Uri uri, RequestCachePolicy uriCachePolicy, Stream stream)
at System.Windows.Media.Imaging.LateBoundBitmapDecoder..ctor
(Uri baseUri, Uri uri, Stream stream, BitmapCreateOptions createOptions, BitmapCacheOption cacheOption, RequestCachePolicy requestCachePolicy)
at System.Windows.Media.Imaging.BitmapDecoder.CreateFromUriOrStream
(Uri baseUri, Uri uri, Stream stream, BitmapCreateOptions createOptions, BitmapCacheOption cacheOption, RequestCachePolicy uriCachePolicy, Boolean insertInDecoderCache)
at System.Windows.Media.Imaging.BitmapImage.FinalizeCreation()
at System.Windows.Media.Imaging.BitmapImage.EndInit()
It seems that others have also noticed and reproduced this error on both XP and Vista. In general image downloading seems to be one of the more perilous operations for WPF to perform. I've seen a number of other process-terminating exceptions caused by images with invalid formats etc, so it is best to be cautious. For this problem caused by IE8 "manually" constructing a web request and downloading the image yourself, and then creating a BitmapImage from the downloaded stream works and does not cause the error.
Both Silverlight 2.0 and WPF support the notion of resources, which can be associated with almost any element - in both SL and WPF the widely inherited-from FrameworkElement (and in WPF the FrameworkContentElement) class exposes a Resources property of type ResourceDictionary. The Resources dictionary is a simple collection of key-value pairs. Almost anything can be stored as a resource, from brushes to templates, data sources, converters, dates, strings and any other .NET object which can be represented as XAML. The key used to retrieve resources can be anything too; however strings or static fields are used.
The current (beta 1) implementation of Silverlight 2.0 has some notable differences to WPF however. The first is that resources cannot be factored into separate files and referenced using the <ResourceDictionary.MergedDictionaries> feature of WPF resource dictionaries. This is unfortunate as it means that the App.xaml file will probably become large and unweildy (and potentially an integration pain point between developers and designers) in Silverlight.
Another notable difference is the way resources are retrieved in code. In WPF FrameworkElement and FrameworkContentElement have methods FindResource and TryFindResource which will look for a resource in the current dictionary with the key provided. If no resource is present for this key these methods traverse the logical tree to ancestor nodes looking for the resource that matches the key. Silverlight 2.0 beta 1 does not expose methods like these (possibly due to the de-emphasis of the separation between the visual and logical trees as concepts in its programming model). You can refer to resources on an object by their key, but no tree searching is performed - if the resource doesn't exist in that resource dictionary then null is returned.
As with WPF, resource retrieval in XAML is done using the {StaticResource} markup extension in Silverlight 2.0. When this markup extension is used the tree is traversed looking for a resource with the specified key. There is no {DynamicResource} markup extension in Silverlight 2.0.
In Silverlight 2.0 Resources can either be given a key (by setting the x:Key attribute) or a name (by setting the x:Name attribute) and both will work for item resolution. Attempting to add two elements with the same value (one by setting the key attribute, the other by setting the name attribute) results in a run-time error.
Silverlight 2.0 promises to bring much of the goodness of WPF to the browser. So how does one of my favourite WPF features - data binding - fare in the new Silverlight 2.0 beta 1 world? To help answer this question I drew up the following summary:
| Similarities |
Differences |
|
Binding Object – the Binding object is present in both SL 2.0 and WPF. Many simple binding scenarios will probably work between the two without modification, but if you’re using the more complex properties of the Binding object in WPF you’ll need to revisit that for Silverlight 2.0 code. The INotifyPropertyChanged interface is also used for change notifications on data objects to be propagated back up to the binding infrastructure. |
Binding Object – although the Binding object exists in SL 2.0 and WPF the SL 2.0 version is very pared-back compared to WPF, having only 5 properties: Converter, ConverterCulture, ConverterParameter, Mode and Source, in contrast to the 20 or so relevant properties the WPF binding object exposes or inherits from its base types. One of the most key properties on the WPF binding object – the path isn’t even a property at all on the Silverlight equivalent. Instead it is specified as a constructor property. Also the Path in SL 2 can’t drill down into indexes or attached properties the way it can in WPF, however you can still access sub-properties on objects. Josh has some screen-shots from Reflector showing the difference in size of the two types. |
|
Data Context – the concept of a Data Context for a control which is propagated from a parent control down to child controls is shared between WPF and Silverlight 2 beta 1. As with WPF the FrameworkElement type adds the DataContext property in Silverlight 2.0 beta 1. |
Binding Markup Extension – although syntactically quite similar (albeit with less properties) bindings in Silverlight are quite different internally to their WPF counterparts because they don’t use a managed Binding Markup Extension. In fact, from what we can see of Silverlight 2.0 beta 1 there ARE no markup extensions of any kind. The Silverlight documentation discusses them here but they don’t appear anywhere in the object model. Presumably the implementations of the various markup extensions are hard-wired into the Silverlight runtime. |
|
Converters – One of my favourite extensibility points of WPF has been completely migrated to Silverlight 2.0 beta 1 (possibly due to the simplicity of the IValueConverter interface). A converter and converter parameter can be supplied as part of a binding. |
Binding to Other Elements – one common scenario is to bind two pieces of WPF UI to each-other. For example binding a slider to the “zoom” on a ScaleTransform. This is done by setting the ElementName property to the name of the element in the current name scope. Silverlight 2.0 beta 1 doesn’t support ElementName as a parameter when binding. This limitation can be worked around fairly easily by creating a simple object with a single property of the type you wish to glue together (double is probably the most common scenario) and then implementing INotifyPropertyChanged on that type. This approach is described in more detail here. |
|
Data Templates – Both WPF and Silverlight 2.0 beta 1 share the concept of templates that can be applied to data. One area where SL 2 differs is that in WPF you can specify a template by the type of object the template applies to (by setting the DataType property). If this is set and no key is supplied (and the Datatemplate is appropriately scoped) the template becomes the default appearance for that type of data item in WPF. The DataTemplate type in Silverlight 2.0 beta 1 doesn’t include this property so all data templates are “keyed” in resource dictionaries or entered in-line. |
Data Triggers – Data templates in Silverlight 2.0 beta 1 don’t have data triggers like their WPF counterparts. This can be worked around using a converter, but requires more code than a data trigger would. Given the changes introduced by the new Silverlight control templating model data triggers going missing are the least of your worries. |
|
TemplateBinding – TemplateBinding is fundamental to styling of controls, and thus has also made its way over from WPF to Silverlight. |
|
|
ObservableCollection
- the generic collection with built-in change notification, ObservableCollection has also been included in Silverlight 2.0 beta 1. The INotifyCollectionChanged interface (the collection equivalent of INotifyPropertyChanged) is also present, and implemented by ObservableCollection.
|
|
Pavan Podilla has added his ElementFlow control to a suite of free open-source tools called FluidKit. ElementFlow is a layout panel that provides several carousel-like layouts, including one quite similar to the "coverflow" from Apple's iTunes application. You can check out some videos of ElementFlow here. My favourite part of ElementFlow is that it has been architected in the "wpf way" - Pavan modified it a while back to be a panel, and it uses templating for specifying how items should appear. In fact in the FluidKit.ShowCase demo that ships with FluidKit, ElementFlow is handling the item layout for an ItemsControl much like I described here. FluidKit also includes a number of other useful classes such as Pavan's drag and drop helpers and an Aero-glass style window.
Component vendor xceed recently released v2 of their WPF Data Grid. It is available in both a free express version and a paid-for professional version. Both new version includes better design time support, and a greatly increased set of editors (like masked text boxes, numeric textboxes etc) for grid items and the pro version includes master-detail binding. [full disclosure: xceed are sponsors of this site].
