Should have one device per application or per form when doing MDI Forms work with XNA?

Question

I am just making a simple editor for a project I am working on and as part of this I need to add a few different MDI forms within a larger container form.

Now the XNA (4.0) example Windows Forms projects use a shared graphics device for all controls, however I was assuming I would have a graphics device per control (assuming we have an XNA-specific panel/control element).

So is there any reasons that you should share the same graphics device? As I can imagine there being problems if you are changing render states in one panel but do not want it to effect the other panels...

It would make sense to share it if the GraphicsDevice object is literally a representation of the underlying graphics card, but thats what the GraphicsAdapter is, so I wasn't sure if there would be any problems with isolating a graphics device per control.

Answer 1

I wouldn't create multiple devices, I'd stick with one that you share across all render windows/controls. A device has some overhead involved in it's existence and you don't gain any advantages to having multiple instances, really.

In fact, it can become much harder to share resources like textures between controls because they must be shared between devices, which I'm not even sure XNA exposes or supports given the version of D3D that backs it. If you can't share resources you have to create multiple copies, which is pointlessly wasteful in terms of memory.

As I can imagine there being problems if you are changing render states in one panel but do not want it to effect the other panels...

Effectively, you can't do this, so it's not a problem. You can only manipulate a Windows Forms control from the thread it was created on (almost always the UI thread), so you generally could not be attempting to change the render state from one control's thread while you are rendering on another control's thread. Even if you did create controls in isolated worker threads you would need to serialize access to non-thread-safe resources anyway, so you'd just have to include the render states in that serialization anyhow (but again, it's not terribly useful to put controls on the non-UI thread).

Create a local abstraction that encapsulates the render state data for a particular control or render window, and in that render window's drawing method, apply those render state changes.