I was told this can be done by passing the locked surface's GraphicsStream.InternalData pointer when creating the Graphics object, presumably using FromHdc or FromHwnd. I can't find the post with the details anymore, and my attempts are failing. Is it actually possible? How do I set it up? With the low quality and speed of GDI+, I should probably use AGG instead, but right now I just need a quick fix.

Look for Surface.GetGraphics. There are some limitations (like no alpha channel) which surfaces can use the method. But it should be easy to use an additional surface and copy it with another method to your final destination.

Right, that was it! But unfortunately I can't get ReleaseGraphics() to work properly - when I later try to lock the surface I get an error that it's already locked.

Any idea why that might be?

It must be related to my using
Texture.GetSurfaceLevel(0);
to retrieve the surface each time I need it.

This method seems to return a new instance of the surface object each time it's called, so it doesn't retain any information about it being locked - thus, when I ReleaseGraphics() on it, the command is just ignored.

Is this a bug in MDX? Or is there a reason for GetSurfaceLevel() to return a new instance each time it's called?

Good question I will check the IL code to see what’s going on behind but this will take some time. In the mean time you should call GetSurfaceLevel only once and store the result somewhere.

I've changed my code as suggested and everything works fine. Looking forward to hear what you come up with!

A short inspection of the critical methods shows me that you have found a real big MDX issue. I would not say that this is a classic bug. It looks more like a general design mistake. Every time you call a MDX method that returns another MDX object it internally ask for the unmanaged object and create a new managed wrapper for it.

Normally this would not be a problem but the wrapper stores some internal data that are used for paired methods like LockRectangle/UnlockRectangle and GetGraphics/ReleaseGraphics. This is the reason why you have to call both methods of such a pair always from the same instance of an object. If you let the garbage collector throw away object after you have only called the first part of a pair you lose this states. There is a high chance that you will never be able to call the second part of the pair successfully.

As I am writing my own managed wrapper for Direct3D 10 at the moment I know that there are at least two different solutions for this problem. But only Microsoft can implement them if you don’t want to write a complete wrapper by your own.

Interesting!

As you're working on a DX10 wrapper - would it be very difficult to create one for DX9? Is your project open source?

MDX isn't bad, but there are some issues that the community could probably solve better than MS (e.g. documentation, dll distribution, an actual 1.0 ETA)

From the technical point of view it would not be that hard to build an alternative wrapper for Direct3D 9/DirectX 9. It should nearly the same extent as the Direct3D 10 version. But I must confess that I am never thought much about such a project as there is an official managed DirectX 9 version. I had started to build a DX8 version shortly after the release of the .net platform. But after the official announcement that DX9 contains a managed layer I had stopped this project.

We (the company I am working for) have not finally decided if we release the source code but the wrapper dlls can be used free of charge. You can find a version over at MDXInfo.com.

You may be right that the community can react fast then Microsoft but if I look at the acceptance of the managed DirectX version against the unmanaged one I am not sure if it would be possible to build a large enough community around an alternative wrapper to keep it alive. Another zombie project over at SourceForge doesn’t help anybody.

Yeah, it's probably not a very good idea, especially as we don't know what XNA will bring to the table. I just often find myself wishing the MDX project was more transparent and that we could have more influence.