Looking for D2X?

July 13, 2009

Even though it’s been quite some time since I released D2X, I still seem to get requests for it trickling in.  The old codeplex project seems to have been ‘pruned’ (for inactivity, one would assume), so here’s a link to the last build I made:

D2X DWG/DXF to Xaml Conversion Toolkit

A word of warning, however – It’s been a couple of years, so the version of the ODA libraries used to read the AutoCAD formats are quite out of date.  The latest AutoCAD releases almost certainly will not be able to be converted.

I should still have the source on an old backup – I’ll post that as well when I’m able to find it.

Good Luck folks!

-F.


D2X Wins!

November 30, 2006

Just in case you haven’t been following along, the WPF\XAML Conversion Tool Contest deadline was October 27th.  Yesterday, the winners were announced, and my DWG/DXF to XAML Conversion Toolkit took the overall award!  As I mentioned in an earlier post, I took D2X in a direction that went beyond the contest judging criteria, choosing to spend some significant time on 2D DWG and DXF conversion.  Ultimately, I felt this functionality would be more useful, even if focusing on it were to reduce my chances of winning somewhat.  I ended up having to cram all of the development into roughly 3 weeks worth of nights and weekends, made up of equal parts “geeky fun” and “exhausting late night coding”.  While I’m (mostly) happy with what I was able to get done in that time period, winning was definitely an unexpected, but welcome surprise.

As thrilled as I am to win, I’d be remiss if I didn’t mention the other fantastic tools that others have created, many which work with file types that weren’t in the contest outline.  The developers of many of these tools didn’t need a contest to convince them to write their converters, which speaks volumes about their willingness to contribute to the early adopter  community.  Mike Swanson, the developer evangelist who ran this contest, created his own SWF to XAML converter, when no one from the community submitted one for consideration – how cool is that? 

At any rate, I’d still love to hear what you think of D2X, and how I could make it better fit your needs – let me know!

F.


…and I’m spent

October 26, 2006

It’s been more than a month since I last posted, but I had a good reason for my absence.

The WPF project I’m involved in for my day job has been going along swimmingly, and nearly all of my off hours time has been going into the D2X DWG/DXF to XAML Conversion Toolkit. I’m really happy with where it’s at right now, although there is still a tremendous amount of work I could sink into it. A while back I blogged about giving back to the developer community – D2X is my attempt to do just that, in my own small way.

I started D2X in response to the challenge posed by Microsoftie Mike Swanson – the WPF/XAML Conversion Contest. Once I started, things just started to roll on their own. One of the target formats specified in the contest outline was DXF, for 3D content. I started at that point, but decided to push towards what developers and CAD users would find most useful – both DWG and DXF support, in both 2D and 3D flavors. Aside from that decision, the decision I’m happiest with was the decision to take the time to put together supporting documentation, and the sample application – these ‘last steps’ are the kind of steps that really help developers understand, and ‘embrace and extend’ new functionality.

So, if you’re even remotely interested in some mixture of CAD and WPF, check out the D2X Toolkit, and let me know what you think. I’m not finished with this – not by a long shot.

Oh, and if you happen to be my wife, thank you for being so considerate about all the household chores I haven’t done since this project captured my attention – I owe you bigtime…:)


XamlWriter Performance: Update

September 18, 2006

About a month ago, I blogged about Xaml serialization, and pointed out a discrepancy between the performance of XamlReader and XamlWriter.  Simply put, serializing WPF objects with XamlWriter is much slower than loading the same objects with XamlReader.  (as of the RC1 bits)  This is somewhat understandable considering how important the Xaml parser is to the framework, but at 5 to 9 times slower, I pointed out that XamlWriter could use some serious love.

Unfortunately, however, I was informed that XamlWriter optimizations were not going to make the release window.

Enter Rob Relyea, Program Manager in the WPF group at Microsoft.  Not content to let ‘sucky’ performance prevail, Rob whipped up a sample implementation of XamlWriter using the underlying APIs.  To make a long story short, it’s twice as fast as the built in XamlWriter, and in my testing seems to work well with a wide variety of WPF objects.  Thumbs up from the developer community Rob – I’m glad Microsoft has people on the job who have obvious passion for what they’re doing.

The code sample is not complete, but it should be trivial to add your own implementation of the methods you require.  The code can be found in this thread in the MSDN forums.


Xaml and System.IO.Compression: Bosom Buddies

August 15, 2006

Once you get past the fact that the word “Bosom” is in the title of this post (does anyone still use this word?) you’ll be able to see that I’m quite pleased with the fact that .NET 2.0 introduced stream compression as part of the framework – finally!

System.IO.Compression introduces a couple of classes:  DeflateStream, and GZipStream.  I’ve been using GZipStream to compress the serialized content of my application, with great results.

Before I continue, a few notes.  It’s been said before, but it’s important to note the distinction between file and stream compression.  In short, if you intend to compress multiple files into an archive, these classes may not be for you.  It is certainly possible to achieve this type of functionality, but that is not what these classes were designed for.  Since these classes are designed to operate on streams, the amount of prediction they can do is limited, which means that the eventual compression will likely be less than what can be achieved with a file compression utility.  At any rate, the most important thing from my perspective is the fact that compression is now part of the framework not that it provides the best possible compression available.  The fact that it operates on streams comes in very handy in the .NET world.

Xaml and GZipStream work together well because of the characteristics of XML.  In essence, the XML format includes a tremendous amount of statistical redundancy (think about the repetition involved in opening and closing tags, etc) which is great from a compression perspective.  In general, the more repetition in your content, the better compression you’ll be able to achieve.  For some background on how compression works, a decent place to start is the data compression wiki.

I’ve been very satisfied with the results of my initial tests – in most cases, I’m achieving at least an 80% compression rate, at a very acceptable performance cost.  In many cases, this allows me to achieve file sizes which are smaller than their original sizes in their binary CAD format. 

So, whether your serializing WPF objects to Xaml, or simply saving XML, System.IO.Compression could be very useful in any situation where size matters.  For information on how to use the classes in System.IO.Compression, developer.com has a short primer that should be enough to get you started.


XamlWriter and XamlReader: WPF serialization

August 12, 2006

One of the most useful features of WPF is the ability to save and load objects with XamlWriter and XamlReader.  There are some limitations to their use, for example, there may be differences in the design time and run time representations of an object – the runtime representation will always be the one that gets saved.  Serialization Limitations of XamlWriter.Save does a pretty decent job explaining the limitations, as well as the scenarios for realistic use of this functionality.

Where XamlReader and XamlWriter shine is when you need to save and load vector graphics.  Most, if not all graphical objects in Windows Presentation Foundation can be persisted in this way.  One area where I ran into a little difficulty was when I attempted to serialize StreamGeometry objects.  For the uninitiated, StreamGeometry is the high performance/low overhead alternative to using PathGeometry.  StreamGeometries represent their data internally as a stream of bytes, which is serialized in path ‘mini-language’. 

Now this is great, since use of mini-language helps keep the size of the resulting markup down, but as I found out, it is important to note that not *all* StreamGeometry states can be represented in this way.  For example, setting stroked=false for any segment of your StreamGeometry will prevent it’s data from being serialized.  It looks like calls to BeginFigure() also require that filled=true be set as well.  This can be confusing, since XamlWriter doesn’t throw an exception – it simply serializes the StreamGeometry with no content.

Another issue has to do with loading serialized StreamGeometries – in the current CTP (and dev) bits, StreamGeometries cannot be loaded, due to some interactions between certain freezables and the Xaml Parser.  In my situation, wrapping up my StreamGeometries into GeometryDrawings works, and I can even retrieve the StreamGeometry from the GeometryDrawing upon load.  Since I also need to save the Pen used to stroke the StreamGeometry, this makes sense in my scenario.  Anthony Hodson from Microsoft also suggested wrapping StreamGeometries in an Arraylist – for more detail, see this thread in the MSDN Avalon forums.

One other issue I have experienced is performance related.  Simply put, XamlReader.Load seems to be a whole lot faster than XamlWriter.Save for the same object.  I’m not surprised, since I’m sure the Xaml Parser has recieved a whole lot more attention than the serialization mechanism behind XamlWriter.Save.  Once I’ve done some more testing with my scenario, I’m hoping to get a developer to comment on this.

Good Times.


The lonely ‘CTP’ existence

August 10, 2006

Ah, the wonders of working with prerelease code. 

Best practices – what best practices?  We’re still building this thing!  For an application like mine, performance is important, so what would be the ‘best practice’ approach for working with geometry at the Visual Layer?  Turns out there isn’t one – which is ok, even understandable.  Exploration is fun right? 

Recently, I came upon a post by a Microsoft developer recommending the use of a class called ‘HostVisual’ to do animation in a thread other than the UI thread.  Seems HostVisual and VisualTarget can ‘work together’ to perform what amounts to some inter-thread communication – and can somehow update the UI.  Since we know the UI can only be updated from the UI thread, this is interesting – I think I could use this type of functionality, but alas the documentation on these two is virtually nonexistent.  I requested the briefest of examples on how to achieve this, but received no response save “we’ve flagged the need to flesh out the documentation in the next version of the SDK”.  So, looks like I’m left to pick over the class hierarchy on my own, and attempt to “intuit” the usage of these classes.

I’ve got the CTP blues.


Follow

Get every new post delivered to your Inbox.