Xaml and System.IO.Compression: Bosom Buddies

August 15, 2006

Once you get past the fact that the word “Bosom” is in the title of this post (does anyone still use this word?) you’ll be able to see that I’m quite pleased with the fact that .NET 2.0 introduced stream compression as part of the framework – finally!

System.IO.Compression introduces a couple of classes:  DeflateStream, and GZipStream.  I’ve been using GZipStream to compress the serialized content of my application, with great results.

Before I continue, a few notes.  It’s been said before, but it’s important to note the distinction between file and stream compression.  In short, if you intend to compress multiple files into an archive, these classes may not be for you.  It is certainly possible to achieve this type of functionality, but that is not what these classes were designed for.  Since these classes are designed to operate on streams, the amount of prediction they can do is limited, which means that the eventual compression will likely be less than what can be achieved with a file compression utility.  At any rate, the most important thing from my perspective is the fact that compression is now part of the framework not that it provides the best possible compression available.  The fact that it operates on streams comes in very handy in the .NET world.

Xaml and GZipStream work together well because of the characteristics of XML.  In essence, the XML format includes a tremendous amount of statistical redundancy (think about the repetition involved in opening and closing tags, etc) which is great from a compression perspective.  In general, the more repetition in your content, the better compression you’ll be able to achieve.  For some background on how compression works, a decent place to start is the data compression wiki.

I’ve been very satisfied with the results of my initial tests – in most cases, I’m achieving at least an 80% compression rate, at a very acceptable performance cost.  In many cases, this allows me to achieve file sizes which are smaller than their original sizes in their binary CAD format. 

So, whether your serializing WPF objects to Xaml, or simply saving XML, System.IO.Compression could be very useful in any situation where size matters.  For information on how to use the classes in System.IO.Compression, developer.com has a short primer that should be enough to get you started.


XamlWriter and XamlReader: WPF serialization

August 12, 2006

One of the most useful features of WPF is the ability to save and load objects with XamlWriter and XamlReader.  There are some limitations to their use, for example, there may be differences in the design time and run time representations of an object – the runtime representation will always be the one that gets saved.  Serialization Limitations of XamlWriter.Save does a pretty decent job explaining the limitations, as well as the scenarios for realistic use of this functionality.

Where XamlReader and XamlWriter shine is when you need to save and load vector graphics.  Most, if not all graphical objects in Windows Presentation Foundation can be persisted in this way.  One area where I ran into a little difficulty was when I attempted to serialize StreamGeometry objects.  For the uninitiated, StreamGeometry is the high performance/low overhead alternative to using PathGeometry.  StreamGeometries represent their data internally as a stream of bytes, which is serialized in path ‘mini-language’. 

Now this is great, since use of mini-language helps keep the size of the resulting markup down, but as I found out, it is important to note that not *all* StreamGeometry states can be represented in this way.  For example, setting stroked=false for any segment of your StreamGeometry will prevent it’s data from being serialized.  It looks like calls to BeginFigure() also require that filled=true be set as well.  This can be confusing, since XamlWriter doesn’t throw an exception – it simply serializes the StreamGeometry with no content.

Another issue has to do with loading serialized StreamGeometries – in the current CTP (and dev) bits, StreamGeometries cannot be loaded, due to some interactions between certain freezables and the Xaml Parser.  In my situation, wrapping up my StreamGeometries into GeometryDrawings works, and I can even retrieve the StreamGeometry from the GeometryDrawing upon load.  Since I also need to save the Pen used to stroke the StreamGeometry, this makes sense in my scenario.  Anthony Hodson from Microsoft also suggested wrapping StreamGeometries in an Arraylist – for more detail, see this thread in the MSDN Avalon forums.

One other issue I have experienced is performance related.  Simply put, XamlReader.Load seems to be a whole lot faster than XamlWriter.Save for the same object.  I’m not surprised, since I’m sure the Xaml Parser has recieved a whole lot more attention than the serialization mechanism behind XamlWriter.Save.  Once I’ve done some more testing with my scenario, I’m hoping to get a developer to comment on this.

Good Times.

The lonely ‘CTP’ existence

August 10, 2006

Ah, the wonders of working with prerelease code. 

Best practices – what best practices?  We’re still building this thing!  For an application like mine, performance is important, so what would be the ‘best practice’ approach for working with geometry at the Visual Layer?  Turns out there isn’t one – which is ok, even understandable.  Exploration is fun right? 

Recently, I came upon a post by a Microsoft developer recommending the use of a class called ‘HostVisual’ to do animation in a thread other than the UI thread.  Seems HostVisual and VisualTarget can ‘work together’ to perform what amounts to some inter-thread communication – and can somehow update the UI.  Since we know the UI can only be updated from the UI thread, this is interesting – I think I could use this type of functionality, but alas the documentation on these two is virtually nonexistent.  I requested the briefest of examples on how to achieve this, but received no response save “we’ve flagged the need to flesh out the documentation in the next version of the SDK”.  So, looks like I’m left to pick over the class hierarchy on my own, and attempt to “intuit” the usage of these classes.

I’ve got the CTP blues.

Hello world

August 8, 2006

An appropriate title for the first post no? 

Since I am likely very alone at this point, I’ll make the introduction brief.  I’ve started this blog to track my little ‘joyride’ with Windows Presentation Foundation.  I’m currently heading a rather ambitious project for my employer that targets WPF.  We’re a niche provider of software and services to the ‘green’ industry (if you’re terribly bored you can guess who) and I’m a Product Development lead in the ‘CAD’ arm of the company.

Naturally, I’m obsessed with vector geometry, which is where WPF’s neat little retained mode graphics system fits in.  I’ll likely be posting a great deal about Visual Layer programming and performance, as these two are terribly important in my world.  Hopefully, I’ll be able to contibute a little something to the early adopter crowd now and then.  At this point, development at the visual layer is still very much a trial and error exercise, and I’m certain I’m not the only one who’d like to see that change.