On a side note, if you haven't noticed the XNA news from GDC, you are really out of the loop. Those guys have got some really cool stuff in the pipeline, especially now that they've settled on a sane distribution model. Zune support should be fun too.
The Evolution of SlimDX
There's been a lot of internal redesign in SlimDX over the last two months. I have to admit that most of these changes were driven by jpetrie and MikePopoloski; my involvement with the project was rather minimal for a long period in the middle. That's life I guess. The result of these changes is evident throughout the internals of the library, and unfortunately throughout SlimDX based code as well. Of particular annoyance is that we changed the semantic model used for managing object lifetimes. But I'll get to that a bit later.
I happened to be looking at the very early revisions of SlimDX yesterday in Google's repository viewer. (They got a new one. It's really nice.) It shouldn't be a surprise that there's no resemblance. The design focus of SlimDX has mutated over the period of about a year. I wrote the initial prototype in January 2007, shortly after completing a C#/MDX game for a course. The goal at that point was very simple: I wanted to get off MDX. In order to accomplish that, I wrote the new library very quickly, starting from a blank slate and filling in functionality until the game was functional again. (This is the only time I've ever used a pure TDD approach to writing software.) There wasn't any work done over the course of the next several months; I simply did some cleanup before revealing the code to other people in May.
The result of this approach was that the original SlimDX was a direct MDX clone, cut down heavily but otherwise identical. Features I never used, such as device events or Get* functions, didn't made it in. There still wasn't a specific design goal at this point, just a push to add more functionality to the prototype. That continued up until the August release, which was substantially filled out but otherwise had the exact same model as my initial draft.
After that, the userbase began to expand significantly, and their complaints plus the complaints of jpetrie and Mike began to drive change. Many of those design changes were driven by the inclusion of new subsystems, especially Direct3D 10 but DirectInput to a lesser extent as well. These architectural revisions were still mainly internal, and most of them didn't leak out much, except in the form of name changes or namespace changes.
We're coming up on the March release now, and the changes are far, far more widespread. Several steps have been taken in order to guarantee that the SlimDX architecture is consistent and maintainable long term. We're getting tired of changing fundamentals, and I think we're pretty close to the final structure of the library. We've added a Conventions page to serve as a development guideline, although that's still being worked on as well. The changes we've made should survive long term, and significantly enhance usability of the library. Unfortunately, they're also breaking changes at the semantic level. The object lifetime management semantics are the biggest change in this regard.
The problem, as jpetrie puts it, is that SlimDX has to play nice on both sides of the fence. Both COM and .NET have to be satisfied as much as possible with what we're doing. We can never screw up the COM side, because if we do we are at risk of leaking memory, trashing the heap, and other similar bugs. On the other hand, if we don't adhere to .NET's conventions, developers are likely to make mistakes that also result in memory leaks. (But that's about the worst that can happen, assuming we don't screw up.)
I'm not going to document the old and new models, as I don't feel this is a good place for it. It's relevant to all SlimDX developers, not just the ones who keep an eye on this space. jpetrie does a reasonable job of summing up the problem in his post anyway. This page sums up the rationale that led to the new implementation, as well. The short version is that now, we simply create new references to existing SlimDX objects whenever possible, rather than continually spawning new SlimDX objects. It's fairly obvious that this is a much better idea.
At the end of it all, our new model still isn't perfect. There are still awkward corners and special cases that will create non-intuitive behavior. I think this is unavoidable no matter what we do; the native and managed worlds are too different for the interaction between the two to be perfect. I feel that the model we've settled on is the idea, because it best serves the needs of the majority of people using DirectX. It's considerably more forgiving than either the old SlimDX model or the MDX model, and because we integrate leak tracking (which has been juiced up, by the way), it's very easy to track down the places where something goes wrong. I'll even go so far as to say that in a number of ways, we're even easier to use than XNA.
