We’ve made some fairly large changes to the ink object model in Avalon.  It differs now from our COM / WinForms Ink object model in several key ways that I’d like to discuss.  In this post, I’ll talk about our decision to remove the Microsoft.Ink.Ink object.

At a high level, there were two main reasons for the changes

1)  Feedback on our COM / WinForms OM

2) Our Avalon inking OM is pure managed code all the way down and it gave us the opportunity to make sure it fits well into the .NET platform

Our existing COM / WinForms platform is largely unmanaged COM code in InkObj.dll, with a thin managed wrapper in Microsoft.Ink.dll.  This strategy was a good one as it helped us make our OM available to a wide range of languages: VB6, C++/COM, C#, VB.NET, etc.  Avalon on the other hand is almost entirely managed code and is not available from VB6, C++ / COM. 

One of the major differences between the Avalon and COM / WinForms inking platform is that that COM / WinForms exposes an ‘Ink’ object that can be thought of as a DOM or database of Stroke data while there is no ‘Ink’ object in Avalon and Strokes own their own data. 

Let’s start by looking at the legacy inking ink platform.

Each collection of Strokes can be thought of as a recordset of Stroke objects.  Thus, to delete a Stroke from the Ink object, you must call Ink.DeleteStroke(Stroke) instead of simply Ink.Strokes.Remove(Stroke).  If you delete the underlying Stroke data from the Ink object, there can still be outstanding Strokes ‘recordsets’ in memory with a reference to a Stroke object that represents the deleted Stroke data.  Microsoft.Ink.Stroke exposes a ‘Deleted’ property to indicate this situation exists.

Each Stroke was identified by its ID property instead of object equality.  Why?  Because of the DOM / Recordset model.  There can be multiple Stroke objects that represent the same underlying data in the Ink object.  The Ink object assigned unique monotonically increasing integers to each Stroke data and it could ensure that there were no conflicts since it owned the data.

The COM / WinForms inking platform was designed with Win32/COM memory management in mind, while the Avalon ink platform was designed for a purely managed environment.  Instead of an Ink object that is a DOM or database of Stroke data, each Stroke owns its own data and is garbage collected when no longer referenced. 

In Avalon, when a Stroke is no longer referenced by any StrokeCollections, it is simply GC’d.  Note that in this model, Stroke.ID and Stroke.Deleted are not needed (and not possible).