After just 4 hours of dedicated optimizations with the aid of the EQATEC profiler for Silverlight - I managed to speed up the rendering pipeline of Balder quite dramatically. The profiler has a great comparison feature - simple and straight to the point. It shows that the rendering pipeline for Balder got optimized at an average og 2.28 times. (RenderingManagerRender) : 

Its been a little more than 24 hours since I started playing with the EQATEC profiler and have identified bottlenecks in Balder that is close to impossible to discover without a profiler. One of things I really liked about the EQATEC profiler was its really easy to use user interface, its super-intuitive and I got up and running in seconds and could drill down straight to the bottlenecks just as fast. What impresses me with the profiler is the speed of it, I've worked with quite a few profilers in the past for the desktop - and they have always surprised me in a negative way with the amount of memory they use and not to mention the enourmous datafiles they generate. EQATECs just feels right, kudos to Richard Flamsholt and his team in Denmark for this product. You can download a free/personal license from here.

I thought I just give a quick guide into how its used.

The profiler is not integrated in Visual Studio and does not need to instrument your assemblies during compiletime, it works on the binary output of your compiled output. After starting the profiler, you need to point the profiler to your output directory in which the binaries for your application resides, typically the bin\debug directory in your Visual Studio project folder. Click the browse button as shown below:

The first time you run it and if you have 3rd party assemblies that are signed you'll be asked to include or exclude these - the default recommendation is to exclude these. There is a resigning option included as well, but I didn't need this so I just skipped them. After it completes gathering your assemblies and recognizes the Silverlight app by finding the testpage and everything, you can go ahead and click the Build button in the lower right corner. It will instrument your binaries and add hooks for all your methods.

Then you just simply click the "Run App" button and your application will start and performance samples will be collected. You now need to play around in your application for the profiler to get enough data to play with.

After stopping your application, you'll be presented with the sample output with details of when it was profiled, its size and total time it ran.

Double click the session you want to view (if you have more than one) and you can start to drill into method calls with the summary sitting on top and a more visualized version of the method with drilldown capabilities at the bottom.

 Simple drill down and you'll see the amount of time spent in every method you drill down into:

And further: 

This is by far, in my oppinion, the best tool that has been released since Silverlight was released. It completes the developer experience and finally we can really show the full potential of Silverlight and the power the CLR actually gives us.

Thanks again to EQATEC for the donation to Balder - we will certainly make use of the license and optimize as close as we can to clock-cycles. :) 

One of the things that has been missing in the Silverlight development story is a proper profiler that is simple to use and does not require you to hack the registry or do complex command line hacks to get it working. The Danish company called EQATEC has been making profilers for a while for the compact framework, but now they have implemented a Silverlight version that I must say I'm really impressed with. EQATEC has donated a professional license to the Balder project and I have already started using it, and my findings are very interesting. I've found more bottlenecks the last 24 hours than I have during the entire course of the project without a profiler. So I'm expecting Balder to get even more speedier in the near future.

If you want to have a look at how the profiler works, Channel 9 has a great video on it here.

Finally after a couple of months of hard work and polishing the code, API and performance, version 0.8.8.6 of Balder is out. A SampleBrowser can be found here for viewing most of the features of Balder.
The features that has changed or is new are as follows:

* Introduced Silverlight in Core, but still maintaining platform independence
  - Using core objects directly in Xaml can now be done

* Removed all controls in Balder.Core.Silverlight.Controls - not needed anymore

* Introduced View namespace with IView interface and Camera implementing it

* Viewport has View property insted of Camera

* Moved rendering from a multithread environment to run synchronously on the CompositionTarget. It gives better performance, due to synchronization issues between all threads. Will be revisited in the future.

* New drawing routines, optimized

* Heightmap primitive

* Box primitive

* Rotation, Scale on nodes

* Cylinder primitive

* DebugLevel is known as DebugInfo

* Material system in place

* Support for ReflectionMapping on materials

* Double sided materials

* Sprite rendering with alpha channel

* NodesControl - datadriven nodes control with templating - In Balder.Silverlight.Controls

* NodesStack - datadriven stacking of nodes with templating - in Balder.Silverlight.Controls

Its been crazy weeks since I decided to pull 0.8.8.5, but it was for the better. The result is that the rendering speed and quality has gone up quite dramatically. The next version of Balder will be 0.8.8.6 and will contain at least the following: 

- Optimized framebuffer management

- Optimized drawing/rendering

- Optimized lighting

- Proper polygon clipping against the viewport 

- Completely refactored way of handling objects, no duplication in the type hierarchy for Balder, like in 0.8.8.0.

- New controls : NodesControl, NodesStack - similar as Canvas and StackPanel works with 2D elements in Silverlight

- New geometry types; Box, Cylinder, Plane

- Transparency for objects / materials

- Introducing the concept of View, you can now create custom cameras

- DebugLevel is no longer flag-based, but a self contained object with properties for all Debug options

- Rendering is now synchronously - gives better framerate in most scenarios, but hogs up rendering event. Ongoing process.

Its been crazy since december with a lot of work being put into Balder and more to come. I don't have a date yet for when I'll have the release, but I'll try to push it as soon as I'm content with the result. 

One of the things I really love in Silverlight is the promotion of non-locking UIs through heavy use of asynchronous operations for things like webservice calls. The main problem though with this is that it is running on a different thread than the UI thread and you can't modify anything on the UI without running on the same thread. This even goes for databinding, so if you have properties on an object databound in the UI and you set the value on any of these properties, you still need to be on the UI thread in order for this to work. This is also true for WPF applications.

The way you could do this is to get an instance of the Dispatcher and use the BeginInvoke() method on it. In Silverlight there is only one Dispatcher and it can be retrieved from the Deployment object in System.Windows; Deployment.Current.Dispatcher. In WPF there can be several Dispatchers, so it gets a bit more complicated, you'd have to do Dispatcher.FromThread() and use the current thread during the add method of your PropertyChanged and store it alongside with the instance of the delegate to know which Dispatcher to invoke a change on.

 When I first wrote my automagically implemented INotifyPropertyChanged post, it didn't have this support. I knew I needed it to support it, but I didn't want to have a dependency directly to the Dispatcher found in the Deployment object, as my unit tests would have a hard time coping with that dependency. I needed to abstract it away so I could have a cleaner way of doing this and be able to test it without too much hassle. By introducing an interface representing the Dispatcher, I was halfway there, but had no way of injecting this into the proxy types being created. The problem is that you can't define a constant on the type that holds a reference to a ref object, it only supports value types. I really struggled a full day with this, I was trying to not have any dependencies from the proxies in order to get the Dispatcher, and I didn't want to tie it up to just be compatible with IoC containers and specifically NInject that I'm using for the most part. The result is that I had to implement a DispatcherManager and have a private field on the proxy type holding a reference to an IDispatcher and let the manager control which implementation it got. This worked out nicely, even though it now have a dependency to the DispatcherManager directly. 

This has all been implemented into the Balder project, as I need it for my SampleBrowser I'm working on, the code is located inside the Notification namespace and can be found here. 

What does it do?
Lets say you have your object like below, the virtuals are in there for the weaver to be able to implement these properties in its proxy (as eplained in my previous post). 

The weaver will then go and inject its magic, the end result is pretty much like this:

Balder is rapidly moving from being a proof of concept for rotating a box in 3D as it was in early 2007 to becoming a quality library that can be used for gaming and line of business applications. Thanks to all that has shown interest in the project by using it, writing books about it, creating your own demos and posting it, and last but not least companies like Sapient - that took a leap of faith and went with Balder for visualization on a Silverlight project they are doing for a client they have.

A little more than a month ago, I came to an agreement with Sapient on helping them out using Balder on a non-disclosed client project. The Balder project itself is not affected by it, licensing or ownership wise. But it is affected in a rather positive way, it gives me the extra motivation to keep adding features and at a much faster rate than before. Although it might seem "quiet" on the outside, seeing thats there been more than 4 weeks since a release - its very hectic from where I'm sitting. I'm at high speed and turning out code as fast as I can. I will try to get a release out now and then, and hopefully we'll see one out in a short time span. More on the upcoming release in another post. Stay tuned.

Recently I've been working on a small Silverlight project at a client and at the same time I've been working on implementing a SampleBrowser for Balder on my spare time, both these applications are using the MVVM paradigm and all that comes with it. One of the things that has really been bugging me is the INotifyPropertyChanged interface, a key interface for making the View observe changes on objects. Not only do you have to implement the same thing over and over again (the notification bit), but also the PropertyChanged event takes an argument that holds the property being changed as a literal. Although, the literal bit can be solved quite easily with some Lambda Expression magic, like I've blogged about in the past. But your still left with writing the same boring notification code over and over again.

I got really inspired by Jonas Follesoes post about how he solved the ever lasting challenge of INotifyPropertyChanged using Castles DynamicProxy to generate a proxy and automatically handle most of it. I read it and automatically started thinking about how I could remove the last bits and make the objects needed notification totally ignorant of the fact they should notify any changes. The Castle approach described by Jonas is very clean and I love working with Aspects like that, but it is pretty much impossible to get it to 100% automatically generate everything. The reason for this is that in the Silverlight runtime, you are not allowed for security reasons to invoke delegates on another type other than your own through reflection. Another issue I had that I could never figure out, was how to tie it in with an IoC container. I couldn't find a way in Castles solution to actually get the proxy type and not the instance, this of course is quite possibly possible, but I couldn't find it at all.

I started earlier today with the idea I could generate the proxy from scratch myself. The idea is to create a new proxy type that derives from the type you want to automatically notify its changes by overriding your properties. The properties you want to automatically notify must be virtual and implement a setter. The weaved version will override these properties and actually forward both the get and the set method of the properties to your type, so you can still do more complex stuff in your property methods. The result is a specialized object weaver for handling INotifyPropertyChanged. The code is too much to include in this post, but you'll find the implementation here and the unit tests here, also it support a couple of attributes - much like Jonas' solution for ignoring and adding other properties it should notify as well. Take a look at the entire namespace for all files needed. Also worth mentioning is that if you define your constructor to have arguments, it will implement a constructor on the proxy that is exactly the same and forward any arguments when instantiated. That way in a typical ViewModel scenario were you have dependencies to typically services, these will be injected when creating an instance of the proxy through an IoC Container.

Using it is very simple, create a class:

Getting the proxy type:

Once you have the type you can bind it in your IoC container or simply use the Activator type and create an instance of it. 

UPDATED 12th of January 2010: Discovered a small bug when I moved it into production, had forgotten to mark the type created with public. Silverlight can't instantiate private types via dynamically from other types. Its all been updated in the repository. 

EDIT 18th of January 2010: Made it dispatcher friendly - read my post about it.  

2010 is just a couple of days away, I thought I'd do a recap of 2009 and what has happened in my little world. :) 

Back in August 2008 Balder was at a proof of concept stage and I had close to abandoned the project, I had so many things I wanted to do which resulted in not doing anything. Along came a couple of emails from Clinton Rocksmith who found the project interesting and wanted to know how he could contribute. I was really surprised, I never imagined anyone actually looking at the project. Timing was a bit off, I had just signed a contract with a new company and never got around to prioritize Balder, other projects always came in the way. Again, a couple of months later the project was at a stand still and I was getting again to a point of almost abandoning it completely. In the beginning of 2009 though, I got contacted by Gastón Hillar who also found the project interesting and wanted to include a couple of samples in his upcoming book. This spun me completely of my axis. I worked closely with Gastón in providing him the best possible solution and bring Balder to a new level. For me this was a true turning point for Balder and I quickly decided to put all other projects on a complete halt and focus my energy on Balder. The result was that we managed to get Balder to an API level that felt a lot better, performance was increased with several hundred percent and the codebase quality was increased dramatically with retrofitting unit tests for critical parts. 

The project was all of a sudden going somewhere, it was time to look for other developers to join in. A good friend of mine; Petri Wilhelmsen joined the project and has contributed a bit and will commit more time next year to the project. Another friend of mine; Raymond Holmboe has been contributing some on and off since I started the project back in the days and will be committing more time next year as well to the project. 

The ultimate result from all of this is that there has been quite a few commercial interests in the project, everything from companies wanting to buy the project as a whole to companies wanting to utilize it professionally. This is something I can disclose more information on later next year. One thing is certain though, Balder will stay open source and free to use.

Also this year, I was suggested as a Silverlight MVP and was eventually moved from Xna to Silverlight. Thanks to Justin Angel for recognizing me and suggesting the move, its a true honor. 

Although I had a very nice job at Objectware, the distance of 125 KM to work one way was to big. Even though I didn't commute everyday, it got to be a strain on my family when I had to go early in the morning and wasn't back till late and most nights after the kids had gone to bed. So I started sniffing the market to see if there was opportunities closer to home. I ended up at a company called Bouvet, and don't regret my decision. Bouvet has in my opinion the right focus for consultants, and it just feels right. Happy to be onboard.

Professionally I've had the opportunity to work full time on a Enterprise Silverlight project, I've worked on two Microsoft Surface projects, some WPF projects and finally ended up spending the last 3-4 months of the year working on an ASP.net MVC project with some Silverlight content.  

Its also been a very busy year when it comes to speaking engagements, I've been part of Microsoft Norways MSDN Live tour, been speaking at NNUG a couple of times, Game Camp, did a Silverlight course. 

2009 has truly been an exciting year, busy, but very exciting. With the release of Silverlight 3 this summer and the beta version of Silverlight 4, I'm at a point were I really can't wait to get out of bed in the morning and just find the keyboard and start hacking away. It has never been more fun to be a developer, a lot is happening these days, not only in the Microsoft arena, but in general. I can't wait to see what 2010 brings.

Happy new year everyone, looking forward to participate next year. Thanks to everyone who has made 2009 so much fun and exciting, especially I'd like to thank my wife and kids, who has really been patient with me and supported me along the way. 

One really important thing when creating a framework like Balder, is to create proper documentation. The purpose of the documentation is for people to get good explanations for the API and samples on how to use it. 

I've been researching quite a bit for finding a good solution for doing this and didn't want to do all documentation by using XML comments only, but wanted more rich content and must admit that I never found any free solutions that I found satisfying. In the past I've used Innovasys' solution called DocumentX and was very happy with it. It might not be the natural choice for an OpenSource project to chose a commercial product, but the quality in which I want the documentation to be in I really wanted to use a product like DocumentX.

DocumentX provides a combination of documentation generated from XML comments in the code and rich text edited content, all mixed in nicely in the development environment; Visual Studio. This makes it easy to use and maintainable.  

Long story short, we've been so lucky to get Innovasys to sponsor  donate a license to actually do this. So a big thanks goes to them for providing the necessary license for this.

We will be working on updating the documentation and get it in future releases and part of the regular development.