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. :) 

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:

A couple of days ago I published a new version of Balder; 0.8.8.5. It had a bunch of improvements in it, especially when it comes to the Silverlight Control support. I had to pull the release mere hours after its release. The reason for pulling it was that I did a lot of optimizations in the rendering, or at least I thought I did. Turns out that when running on a very fast Dual core or Quad core computer, it was faster - but on slower machines, it turned out to be quite slow. 

Instead of reverting the entire optimization, I've decided to actually get the performance up quite a bit. I've been working on a new rendering pipeline that would increase the performance dramatically, so no time like the present.

The biggest change however with the release was the Xaml support. In the Development branch over at GitHub you will find source code with the rendering pipeline being the same as in version 0.8.8.0, but with all the new Xaml support. So if you can't wait for the optimizations and want to get your Xaml right from the start - you should go pull the latest on the Development branch and compile the binaries yourself. In fact, it should be fairly simple to do it, just download it and run the build.cmd file from a command prompt and it will output a Drop directory with all the binaries in it.

On the 9th of February, Software 2010 is kicked off. Petri Wilhelmsen and myself will be holding an hour on game development with managed code using Microsoft Xna and Silverlight (featuring Balder). We will be focusing on 3D development and cross-platform using .net.

Really looking forward to doing a co-op with Petri.

For more details and signup, go here. 

2010 is going to be a busy year for me, along side consultancy for several customers, I've been scheduled to do a few courses. Silverlight is the topic for all but one of the courses.

You'll find all the courses in this overview of all of Bouvets courses here.

Even though, listed as Silverlight 3 specific, they will be focusing on Silverlight in general and will include some of Silverlight 4 as well. We're looking into putting up a Silverlight 4 specific course as well. 

So, if you want to get your hands dirty and start learning Silverlight, these courses are the place to be. 

Update 9th of December 2009, direct links to the courses:

We're not about to slow down the development of Balder anytime soon, next release is something we're already hard at work with. 

If you want to be influence the priority or have features you'd love to see in it thats not already on the list, please don't hesitate to go to our Issue list over at GitHub and vote, comment or add new issues. You'll find the issue list here. 

We're getting closer to the BETA mark for Balder, and we're starting to get most of the features we want in for version 1 ready. The latest feature is the ability to declaratively through Xaml get Balder up and running. Current release is versioned 0.8.7 and can be found over at the Balder page at Codeplex.

By adding the following namespace declaration in your Xaml file:

You now get a set of extra controls that can be used.

First off is the RenderingContainer:

You need to specify the Width and Height, as that is used to setup the display properly. The BackgroundColor property can be any color, including transparent - which is great if you want to mix with existing Silverlight controls on your page. 

The next control we've added is the Mesh control, it enables you to add any Mesh from a file/resource to the RenderingContainer. You do this by accessing the Nodes property on the Container and putting up a RenderedNodeCollection and put your Mesh(es) within that.

For now, there is a limited amount of DependencyProperties exposed, so manipulation via Storyboards aren't possible today, but will be very soon. The only way to access this is by hooking up the Updated event on the RenderingContainer and implement codebehind logic for it, something like this:

Last but not least, to get it all working, you need to initialize Balder. In your App.xaml.cs file, during the Application_Startup event, you need to add one line of code. It is very important for now that you add that line before your page (RootVisual) is created and set.

I you want to use it the "conventional" way - non Xaml based, you need to add a similar line of code, but that line of code needs to be added after the page has been created. This is something that makes absolutely no sense and is something we're trying to fix and make it a lot more sense. Our goal is to get rid of that line of code all together.

A little note, we're not trying to mimick the WPF 3D namespaces at all, we're going our own direction. We don't feel the urge to replicate those, as the purpose of Balder is very different. 

I just got an email from a guy that watched my WPF talk on the MSDN Live tour in Trondheim, he had downloaded one of my samples from that talk and gave it a go. But he constantly got this "Script Error" thing. The demo was using the WPF MapControl for Virtual Earth maps. It worked OK in all browsers he had tried. Kinda odd I thought. 

The error message was "String was not recognized as a valid boolean". I googled the error message without any concrete results.

Then it struck me; "could it be... Naahh.. It couldn't,  lets try switching regional format settings.." - I always set mine to English - U.S., without really having any good reason for doing so, seeing that I live in Norway. Anywho, I switched it to Norwegian, and there the same error was. 

The simple solution, codewize, is to set the CurrentCulture to be Invariant:

I haven't had time to investigate why this happens, but it sure is kinda odd, since running the map in a browser works and the WPF Control is in fact just a WebBrowser control, using the same browser.