There can be many GraphicsDeviceControl instances in use at the same time. In the interest of efficiency, you only want to create a single underlying GraphicsDevice object. This is managed through the GraphicsDeviceService class, which creates and owns the GraphicsDevice. A reference counting system tracks how many GraphicsDeviceControl instances are using the shared GraphicsDeviceService. In the AddRef method, GraphicsDeviceService checks whether this is the first control to require a graphics device. If so, it creates the singleton instance. Otherwise, it just reuses the existing instance. In the Release method, it checks whether this is the last control to finish using the graphics device. If it is, it disposes the shared GraphicsDevice.

A problem arises when more than one control is sharing a single graphics device: what size back buffer should you give that device? The controls might not all be the same size, but it would be inefficient if you had to reset the device in order to resize the back buffer every time you wanted to draw onto a differently sized control. The solution is to size the back buffer to fit the largest control, but then use only part of it if you are drawing onto a smaller control. This is handled by the GraphicsDeviceControl.BeginDraw method, which sets the viewport to only render onto the top left portion of the back buffer (corresponding to the size of the current control), and by the GraphicsDeviceControl.EndDraw method, which uses an overload of GraphicsDevice.Present that lets you specify exactly which area of the back buffer to copy onto the display. EndDraw is also responsible for passing the correct window handle to Present, so that it knows onto which of the many possible controls to render.

The graphics device is not always guaranteed to be available. When you lock your desktop, or if some other program switches to full-screen 3D mode, the device becomes desktop. Also, if some other program switches to full-screen 3D mode, the device becomes inaccessible temporarily. After this happens, you must reset the device before you can continue using it. These situations are normally taken care of by the XNA Framework Game class. Since you are not using Game, you must handle them yourself. This is done by the GraphicsDeviceControl.HandleDeviceReset method, which is called by BeginDraw. This checks the current status of the device. If the device is lost, it returns an error message, which keeps you from using the device to draw. If the device was lost and now needs to be reset, or if the device back buffer is too small for the control onto which you are trying to render, it will reset the device. This ensures it is valid and of a suitable size.

WinForms controls are not only used when you run your program. If you load the MainForm.cs file into the designer, you will see previews of the two controls that it contains. These previews are implemented by the designer loading up and creating an instance of your custom control class. In most cases, this is useful behavior, but an animating 3D graphics control is too resource intensive to be running inside the designer!

To gracefully handle the designer scenario, the GraphicsDeviceControl class checks its DesignMode property from the OnCreateControl method. If it is running inside the designer, it skips initializing the graphics device. As a result, it will never call the Initialize or Draw methods. Instead, it uses the much simpler PaintUsingSystemDrawing method to show a placeholder representation of the control. You can see this in the designer.

In order to load graphics content such as models, textures, or SpriteFont data, you need two things:

First, you must build the content alongside your project. This is done by adding an XNA Framework content project to your solution. Because content projects are not directly able to build themselves, we must also add a game library project to build the content. First, add a new "Empty Content Project" to your solution, and add your content files (such as the Arial.spritefont used in this sample) to the new content project. Second, add a new "Windows Game Library" project, which will be used to build the content. Because we do not care about actually adding any code to this library project, you can delete the .csproj file that was added to it by the project template. Third, right-click the game library project, choose Add Content Reference, and select your content project. Finally, right-click the main WinForms project, choose Add Reference, and select the game library project. Your content files will now be built using the XNA Framework Content Pipeline, and automatically copied to the build output folder alongside your executable.

Second, you must create a ContentManager to load your content files. The ContentManager needs access to your custom GraphicsDevice in order to load graphics data. You must hook up some plumbing to connect the two. Your GraphicsDeviceService class implements the standard IGraphicsDeviceService interface. ContentManager uses this interface whenever it needs to locate the graphics device. To expose this interface, GraphicsDeviceControl provides a Services property, and registers the IGraphicsDeviceService inside its OnCreateControl method. With this plumbing in place, you can pass your custom Services into the ContentManager constructor, as seen in the SpriteFontControl.Initialize method.

The approach used in this sample requires all content files to be known ahead of time so they can be built as part of the project. For a more dynamic approach to building and loading content, see the WinForms Content Loading Sample.

WinForms apps are not usually animated. They typically just sit there, doing nothing, until an event notifies them of a user action such as a key press or mouse event. At this point, they spring into action, process the event, redraw the screen if there were any changes, and then go back to sleep.

Games do not work like that. If you use the XNA Framework Game class, it will call your Update and Draw methods in rapid succession, even when the user is not providing any inputs.

When you replace the Game class, you must decide whether you want to use WinForms-style event-based updates, or game-style constant animation. This sample demonstrates both approaches. The SpriteFontControl class is not animated: it just uses the Draw method to display some text. It will redraw itself only if the window is resized or invalidated by some other window being dragged over the top of it, in exactly the same way as any normal WinForms control. On the other hand, the SpinningTriangleControl uses game-style animation. This is implemented by a single line in the Initialize method.

        // Hook the idle event to constantly redraw our animation.
        Application.Idle += delegate { Invalidate(); };
      

This causes WinForms to redraw the control any time it runs out of other events to process. In the Draw method, you then use a Stopwatch to measure how much time has passed since the previous Draw. This time value is then used to control the speed of the spinning triangle.