Charlie Robbins

Increase the performance of large WPF applications across the board

Tue, 11 May 2010 04:22:00 GMT

I was just debugging a very long render delay in some WPF code and I came across this little tidbit.

The quote of interest is: “Each time a control references a ResourceDictionary XAML creates a new instance of it. So if you have a custom control library with 30 controls in it and each control references a common dictionary you create 30 identical resource dictionaries!”

Normally that isn’t a huge problem, but when you consider the way that I personally (and have suggested to others) that they organize their resources in Prism projects it gets to be a serious problem. For example, let’s say we have this project structure:

 
/MyProject.Resources
    /Resources
        -Buttons.xaml
        -DataGrid.xaml
        -Global.xaml
        -Brushes.xaml
        -WindowChrome.xaml
        -Icons.xaml

/MyProject.Module1
    /Resources
        -Module1Resources.xaml  
        (References all Dictionaries in /MyProject.Resources/Resources/*)
    /Views
        -View1.xaml
        -View2.xaml

/MyProject.Module2
    /Resources
        -Module2Resources.xaml   
        (References all Dictionaries in /MyProject.Resources/Resources/*)
    /Views
        -View1.xaml
        -View2.xaml

/MyProject.Shell
    /Resources
        -ShellResources.xaml   
    /Views
        -MainShell.xaml

If in your views you reference the module-level ResourceDictionary (which helps for maintainability and modularity) then every time you create an instance of View1.xaml for example, you would have to parse all the ResourceDictionaries in /MyProject.Resources/Resources/* every time. And if in View1.xaml you have a reference to say View2.xaml now you’re parsing it all twice every time! This isn’t really a memory concern but it is a huge performance concern. There can potentially be thousands of lines of XAML code to parse and the time really does add up as your views become nested and more complex

I recently switched all of the MergedDictionary references:


<ResourceDictionary>
    <ResourceDictionary.MergedDictionaries>
        <ResourceDictionary Source=”/SomeDictionary.xaml” />
    </ResourceDictionary.MergedDictionaries>
</ResourceDictionary>

To use the attached SharedResourceDictionary which shadows the Source property and keeps a global cache of all ResourceDictionaries parsed:


<ResourceDictionary>
    <ResourceDictionary.MergedDictionaries>
        <SharedResourceDictionary Source=”/SomeDictionary.xaml” />
    </ResourceDictionary.MergedDictionaries>
</ResourceDictionary>

And I saw a performance increase of almost two orders of magnitude: From almost 6000ms to 200ms. As always, this code is available on GitHub.

Posted by Charlie Robbins

MIX10 Keynote Redux : Windows Phone, and Silverlight 4

Mon, 15 Mar 2010 18:19:00 GMT

Although the software announcements made today were somewhat disappointing (no releases, just more betas, CTPs, and RCs) the cross-platform functionality offered by XNA 4.0, Silverlight 4.0, Visual Studio 2010, and Windows Phone 7 were compelling. A number of partners gave demos today that showcased some of the really interesting new features of Blend 4 Beta [download here] that I will be discussing more later tonight:

eBay demos Desktop Simple Lister (with help from Cynergy)
Netflix demos Smooth Streaming on WP7
Foursquare demos location aware services WP7
Other great demos: Seesmic, Major League Soccer, and Shazaam

Another big announcement was that they’ve open sourced the Silverlight media framework, that was used to deliver the smooth-streaming HD experience for the 2010 Vancouver Olympic games. The code is available at http://smf.codeplex.com

The focus was very strong on targeting multiple platforms that support Silverlight or XNA with a single code-base. This ubiquity of development has always been a major goal for Microsoft and so-far the case they’ve made is very compelling. I can’t wait to dig into the nuts and bolts of it and post more developer and designer focused analysis.

Posted by Charlie Robbins

MIX10 debuts 4s, 7s, and 10s

Mon, 15 Mar 2010 15:27:00 GMT

Microsoft made a flurry of announcements this morning via press release (link to come). As I watch Sterling Quinn, the 16-year-old Yo-Yo champ (20 minutes is too long for a warm-up FYI) I’ve read that Microsoft has:

“Announced the availability of comprehensive tools”

Visual Studio 2010 Express for Windows Phone
Windows Phone 7 add-in to use with Visual Studio 2010 RC
XNA Game Studio 4.0
Windows Phone 7 Series Emulator for application testing
Expression Blend for Windows Phone CTP

“Available for download today”:

Silverlight 4 RC
Expression Blend 4 Beta – “New features such as Path Layout enable developers and designers to build and animate innovative user interface design via a groundbreaking visual layout mechanism, without the need to write code.”

“Several leading companies will be creating exciting applications and games for Windows Phone 7 Series.”

“Silverlight adoption has continued at a rapid pace with installations approaching 60 percent of all Internet devices worldwide – an increase of nearly 15 percentage points in just four months.”

More to come. Stay tuned in here or follow me on Twitter @indexzero.

Posted by Charlie Robbins

Packed and ready for #MIX10

Fri, 12 Mar 2010 21:10:00 GMT

MIX10 gets started this Sunday. Looking forward to seeing what Microsoft et al. have up their sleeves for Windows Phone, Silverlight 4 and WPF 4. There also seems to be a stronger focus on web standards and Javascript this year:

Here’s a list of some of the talks that I’m planning on attending:

You can read more about my adventures on the floor at MIX10 by following me on Twitter, @indexzero, or checking back here periodically. Hope to see some of you there!

Posted by Charlie Robbins

XamQuery: Reconciling the "theory" and "reality" of WPF vs. Silverlight

Mon, 22 Feb 2010 16:07:00 GMT

Disclaimer: This technology does not actually exist yet, I am looking for feedback about this idea and anyone interested in working on it.

I’m sure a lot of you have seen this image. It highlights some of the pain of working with Silverlight coming from a WPF background.

It occurred to me over the weekend that this is really a statement about the consistency of the implementation of XAML DOM APIs. With that in mind the next logical conclusion was that there is a very important parallel in the Javascript world, i.e. the consistency of the implementation of the Javascript and HTML DOM APIs. Thankfully since about 2005, much of this pain has been encapsulated into jQuery.

So what about XAML? What can we do about it? This is where XamQuery would come in. Here’s a highlight of the core features I see and where I have needed them:

A XAML DOM selector engine similar to Sizzle. Given that XAML doesn’t have complex selector syntax like CSS this would essentially be a highly optimized tree walker for the VisualTree that would wrap the disjoint APIs in WPF / Silverlight for getting visual parents and children.
A set of fluent APIs for creating XAML DOM objects (Panels, Controls, etc) that would wrap some annoying inconsistencies when travelling between Silverlight and WPF as well as making it easier to do things in code that are painfully verbose in pure XAML (I think states of the VSM is a great example of this).
A simple plug-in system for System.Interactivity Attached Behaviors to attach into. This would mirror the jQuery plugin system where each selector statement actually returns the jQuery object which you can then call plugins on.

Feel free to contact me directly about this idea. I’m looking to get some like minded developers together to work on this. I think that this could be the thing that takes WPF and Silverlight development to the next level.

Posted by Charlie Robbins

Parsing JSON into dynamic objects using MGrammar and C# 4.0

Thu, 11 Feb 2010 20:11:00 GMT

I gave a talk last week at the New Jersey .NET User Meetup Group on designing textual DSLs using MGrammar. You can download the slides here: Textual DSLs with MGrammar. The code portion of the project was focused around developing a JSON parser into dynamic objects in C# 4.0. JSON has become an increasingly popular data format over the last several years for it’s flexibility and simplicity. The entire JSON specification can be summarized in just five words: objects, arrays, values, numbers, and strings. Each of these diagrams has a clear representation in MGrammar shown below:

Objects


syntax Object 
  = ObjectStart first:KeyValuePair rest:ObjectPart* ObjectEnd => Object { Pairs { first, valuesof(rest) } };

syntax ObjectPart
  = Comma pair:KeyValuePair => pair;

syntax KeyValuePair
  = key:String Colin value:Value => Pair { Key { key }, Value { value } };

Arrays


syntax Array
  = ArrayStart first:Value rest:ArrayPart* ArrayEnd => Array [ first, valuesof(rest) ];

syntax ArrayPart
  = Comma value:Value => value;

Values


syntax Value 
  = string:String => string
  | number:Number => Number { number }
  | object:Object => object
  | array:Array => array
  | primitive:Primitive => Primitive { primitive };

Numbers


token Number = Minus? Digit+ ('.' Digit+)? Exponent?;
token Exponent = ("e" | "E") Sign? Digit+;
token Digit = "0" .. "9";
token Sign = Plus | Minus;
token Minus = "-";
token Plus = "+";

Strings


syntax String = '"' text:(text:StringText | empty) '"' => String { valuesof(text) } ;
token StringText = !('\u0022')+;

Inside the Parser

Much of the actual parsing is done using simple LINQ expressions. First through, you have to install Visual Studio 2010 and the SQL Modeling November 2009 CTP (formerly “Oslo”) and created a new “Oslo Library.” This is important because it sets up all the M and MGrammar dependencies for you.

After you’ve created your Oslo Library, you must add your *.mg file and set the build action to “MCompile.” This will use the M tools to compile the *.mg file into a *.mx image. After that’s completed we can create our parser at runtime:


MImage grammar = new MImage(@"jsonm.mx");
grammarParser = grammar.ParserFactories["jsonm.jsonm"].Create();
grammarParser.GraphBuilder = new NodeGraphBuilder();

Now that we have our parser we can use that to parse the raw text into MGraph:


var inputText = new StringTextStream(sourceText);
var errorReporter = new ParserErrorReporter();
Node rootNode = (Node)grammarParser.Parse(inputText, errorReporter);
JsonmObject obj = ParseObject(rootNode);
return obj;

The rest of the process uses a series of LINQ expressions using some extension methods (included with the project). Here’s an example of how objects are parsed:

private static JsonmObject ParseObject(Node objectNode) { JsonmObject jsonmObject = new JsonmObject();

List<Tuple<string, object>> keyValuePairs = objectNode
    .Edges.FindNodeWithBrand("Pairs")
    .Edges.FindNodesWithBrand("Pair")
    .Select(node => ParseKeyValuePair(node))
    .ToList();

foreach (Tuple<string, object> pair in keyValuePairs)
{
    jsonmObject.TrySetMember(
        new DynamicDictionaryMemberBinder(pair.Item1, false),
        pair.Item2);
}

return jsonmObject;

}

You can see in the above example that in addition to parsing the MGraph, it sets members on our dynamic dictionary. This is how we can parse some sample JSON like this:


{
    "Object" : 
    {
        "String" : "StringValue",
        "Number" : -1.4e1,
        "null"   : null,
        "true"   : true,
        "false"  : false
    },
    "Array"  : [ "StringValue", 42, false, true, null ],
    "String" : "StringValue",
    "Empty"  : "",
    "Number" : -1.4e1,
    "null"   : null,
    "true"   : true,
    "false"  : false
}

Into a dynamic object using our parser like so:


dynamic result = JsonmParser.Parse(new Uri(Environment.CurrentDirectory + @"\sample.json"));
Console.Out.WriteLine(result.Object,String); // ==> "StringValue"

As always this code is on GitHub. I look forward to see more parsers in MGrammar in the future, send any MGrammar hacks my way in email or comments!

Posted by Charlie Robbins

Capturing Raw Images from the Microsoft Surface

Fri, 22 Jan 2010 05:25:00 GMT

Surface Multi-touch

As I mentioned in a previous post the Microsoft Surface implements multi-touch using infrared computer vision as opposed to a capacitive approach. This is interesting for a couple of reasons. First it allows the Surface to recognize a very large number of touches. Second, it allows ambitious developers to tap directly into this infrared image data to perform more complex operations (like shape recognition). Getting at this information however is not entirely straight forward though. To simply things I created an attached behavior.

Attached Behaviors

Attached behaviors are something that I’ve blogged about before. They are a very convenient way to add user interface behavior to controls without having to implement a proper subclass. This behavior also implements a custom attached event, which allows you to easily handle and process images captured from the Surface.

Using the Behavior

Using the behavior is simple; you just have to include the library in your solution, add the xmlns and set a couple of attached properties and an event handler:


<s:SurfaceWindow
  behaviors:SurfaceWindowRawImageCapture.IsEnabled="True"
  behaviors:SurfaceWindowRawImageCapture.RawImageCaptured="YourEventHandler">
  (...)
</s:SurfaceWindow>

Optional Parameters

This behavior is designed to be flexible. There are several parameters that allow you to take advantage of this flexibility.

UseExplicitCapture=(true | false)

Setting this property to true will disable the attached event from being raised. It is false by default. Use it if you want to capture images programmatically which is explained below.

SaveTo=”C:\path\to\captured\images

Often it may be necessary to save the images that you capture to a specific location. If you set this property all images captured by the behavior will be saved to the specified directory.

Capturing Images Programmatically

The one drawback to the way that the Surface SDK allows developers to capture raw images is that the ContactDown event must be handled on the instance of the SurfaceWindow itself. What that means is that your attached event handler has to also be on the SurfaceWindow itself. The solution to this limitation is to call the behavior programmatically from your own code:


SurfaceWindowRawImageCapture.CaptureRawImageAsync(
    Application.Current.MainWindow as SurfaceWindow,
    new Rect(100, 100, 100, 100),
    result =>
    {
        // Code to execute when the result has been captured
    });

The Rect that is passed to the method defines an area to crop the entire Surface image. This is useful if you are only interested in a small sub-area of the total Surface. The callback that is passed to the method will be executed after the image has been captured.

Let me know if you run into any issues with the behavior by emailing me: charlie [you know] robbins [obviously] gmail [you know] com. As always, all of this code is available under the MIT license on GitHub.

Posted by Charlie Robbins