GDI+

As I upgraded the hard drive on my machine today --which took a few hours to copy the rats' nest that is my home directory-- I begun the process of assimilating the GDIPlus Flat API.

A few weeks ago, Alexandre Pigolkine, Jordi Mas and myself were discussing the development roadblocks that we had with System.Drawing (as part of the Windows.Forms effort). The problem is that we made one of the most common engineering mistakes: when faced with the issue of multiple choices, instead of choosing one, we chose them all.

Being seasoned C# developers, we created an internal interface, and had each backend implement the interface. Then the official System.Drawing API was implemented and it became a multiplexor for the various implementations. We had Win32, Xr and Gtk backends. Of course the issue is that improving the backends becomes fairly hard: a change has to be reflected in five places: three backends, the interface and the multiplexing call site. Not terribly hard for one or two API calls, but it starts to become hard with an API as big as this one. I take all the blame for the mistake.

After some discussion, we decided on a new strategy: System.Drawing would only have one implementation, and this implementation would be based on GDI+. On Windows, the implementation would just call into the real GDI+ library, and on Unix systems we would provide a full implementation of it. To implement GDI+ on Unix, we have based our implementation on Cairo which has pretty much the same imaging model that GDI+ (and PDF) have.

This has several advantages: we maintain and write less code; we can test against the real GDI+ implementation on Windows and remove a variable in the debugging process; and we can contribute this code back to the Wine project.

But plenty of assumptions we had made before do not apply necessarily now. Before we had a managed implementation of the image loaders: it was just as fast as the C code and by virtue of being C# code, by extension it was cooler. But now in this GDI+ world, we will move things like the image loaders into the C code API, and the C# code will become thin wrappers around it.

The above also explains why there is a regression in Windows.Forms and System.Drawing on CVS as opposed to the latest official Mono release. So now I should be able to assist the System.Drawing developers.

Mono Installers

The upcoming Mono not only will add Cairo as a depedency (if you care about System.Drawing), but our internationalization support will also require the International Components for Unicode library.

We will continue to provide packages on Red Carpet, and RPMs on the site for downloading, but we are seriously considering reusing the Ximian Desktop installer to install Mono on a machine. That means that instead of downloading a dozen packages from our site, you would only download one. This hopefully will reduce the number of problems that people have with installations and we would also ship the Apache module pre-configured in the distribution.

Duncan is researching this, and we will keep people posted.