Monthly Archives: January 2010

Upcoming Balder release – 0.8.8.6

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. 

 

Upcoming Balder release – 0.8.8.6

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. 

 

Dispatcher Safe INotifyPropertyChanged

Update, 19th of November 2011:

Eduardo Elias Mardini Bitar did an article for the CodeProject with some updates and improvements.

 

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

[code:c#]
public class Employee
{
    public virtual string FirstName { get; set; }
    public virtual string LastName { get; set; } 
}
[/code]

The weaver will then go and inject its magic, the end result is pretty much like this:
[code:c#]
public class EmployeeProxy : Employee, INotifyPropertyChanged
{
    private IDispatcher _dispatcher = DispatcherManager.Current;

    public event PropertyChangedEventHandler PropertyChanged;

    public override string FirstName
    {
        get { return base.FirstName; }
        set
        {
            base.FirstName = value;
            OnPropertyChanged("FirstName");
        }
    }

    public override string LastName
    {
        get { return base.LastName; }
        set
        {
            base.LastName = value;
            OnPropertyChanged("LastName");
        }
    }

    private void OnPropertyChanged(string propertyName)
    {
        if( null != PropertyChanged )
        {
            if( _dispatcher.CheckAccess() )
            {
                PropertyChanged(this, new PropertyChangedEventArgs(propertyName));
            }
            else
            {
                _dispatcher.BeginInvoke(PropertyChanged,this, new PropertyChangedEventArgs(propertyName));
            }
        }
    }

}
[/code] 

Dispatcher Safe INotifyPropertyChanged

Update, 19th of November 2011:

Eduardo Elias Mardini Bitar did an article for the CodeProject with some updates and improvements.

 

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

[code:c#]
public class Employee
{
    public virtual string FirstName { get; set; }
    public virtual string LastName { get; set; } 
}
[/code]

The weaver will then go and inject its magic, the end result is pretty much like this:
[code:c#]
public class EmployeeProxy : Employee, INotifyPropertyChanged
{
    private IDispatcher _dispatcher = DispatcherManager.Current;

    public event PropertyChangedEventHandler PropertyChanged;

    public override string FirstName
    {
        get { return base.FirstName; }
        set
        {
            base.FirstName = value;
            OnPropertyChanged("FirstName");
        }
    }

    public override string LastName
    {
        get { return base.LastName; }
        set
        {
            base.LastName = value;
            OnPropertyChanged("LastName");
        }
    }

    private void OnPropertyChanged(string propertyName)
    {
        if( null != PropertyChanged )
        {
            if( _dispatcher.CheckAccess() )
            {
                PropertyChanged(this, new PropertyChangedEventArgs(propertyName));
            }
            else
            {
                _dispatcher.BeginInvoke(PropertyChanged,this, new PropertyChangedEventArgs(propertyName));
            }
        }
    }

}
[/code] 

Sapient using Balder for client project

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.

INotifyPropertyChanged – Automagically implemented

 

Update, 19th of November 2011:

Eduardo Elias Mardini Bitar did an article for the CodeProject with some updates and improvements.


 

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:

[code:c#]
public class ViewModel
{    
    public virtual string SomeString { get; set; }  

[/code]

Getting the proxy type:

[code:c#]
var proxyType = NotifyingObjectWeaver.GetProxyType<ViewModel>();
[/code]

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.