Vertex Shader Model 1.1

Pixel Shader Model 1.1

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 go on 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. There is no direct way to create a content project. You can make one by creating a temporary "Windows Game" project, then copy the resulting .contentproj file into the same directory as your WinForms application and add it to the solution. The .contentproj extension is not recognized by the Add Existing Project dialog box, so you must type in the entire project file name (including extension). You can now add content files, such as the Arial.spritefont used in the sample, to this content project. To ensure the content project will always be built before you run the program, right-click the main project, choose Project Dependencies, and check the content project. To make sure the output content files are placed in the right directory, open the properties for the content project, and set its Build / Output path property to the correct location (make sure you do this for both the Debug and Release project configurations).

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 don't 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. The SpinningTriangleControl, on the other hand, 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.