[subheading]Resizing Windows (Swap Chains) in D3D11[/subheading]
Most rendering frameworks (at least in my experience) start out with statically defined window sizes. Nearly all sample applications are defined to utilize a static window size, and the corresponding resources that go along with it are also statically sized. This includes the swap chain for rendering into the window, as well as any other resources that a particular rendering setup may use (such as the GBuffer size in a deferred renderer). This is fine for samples, since they aren't intended to manage resizable windows. However, if you decide to take your sample engine to the next step, it becomes necessary to support a user resizing their window...
There is some fairly clear guidance about how to resize a swap chain in D3D11 provided by Microsoft, which you can find here. Since D3D10, the low level windows surface API is DXGI - this is different than it was for D3D9, which came around before DXGI existed. In any case, the general advice is that a D3D11 application should resize a window's swap chain any time it receives a WM_SIZE message, and it should use the IDXGISwapChain::ResizeBuffers(...) method. This is a fairly simple operation, and as long as you build some infrastructure into your application for handling windows messages, then you should be in pretty good shape.
[subheading]Some Small Complications[/subheading]
Of course, things are never as simple as advertised. As mentioned in the preceding link, an application has to release all references to the texture resource supplied by a swap chain before it can be resized. This includes all direct Texture2D references, any resource views to that texture resource, AND any pipeline bindings that have used the texture resource. That is all perfectly clear, but if you have implemented multithreaded rendering, then that further complicates things by requiring all deferred contexts, immediate contexts, and command lists that have used the swap chain's texture resource to release them (via a clear state call). And of course, you have to take care of resizing the depth stencil resources, viewports, and so on as well...
This is where it can be a bit tricky to implement the resizing function. If you haven't implemented your renderer to centralize your references to their corresponding API objects, it can get pretty ugly pretty quickly. Fortunately in HG3 I have used a proxy class to represent my resources within the engine, which only uses indices to reference resources. The actual resource pointers are all housed within my renderer class, which compartmentalizes any actions that need to capture all references to a resource (which in this case is a resize operation). It may cost a tiny bit in performance to use a proxy class, but in the end, unless you are writing a renderer for Battlefield 3 (or some other AAA game) then this tiny amount of performance cost is not likely to be noticed...
Anyways, I now have resizing up and functional within the engine. It works on the WaterSimulationI sample, but I am incorporating the changes to the remainder of the sample applications before I push the changes to the Hieroglyph repository. Here are a couple of screen shots before and after a resize event, demonstrating the usage of the resized swap chains:
There are still a few robustness improvements that I am working out as well, but as soon as I finish them up the results will be a fully updated set of samples that will correctly update as a user changes the window size. As a nice bonus, this also includes when a user switches to full screen - it simply acts like another resize event, regardless of if the window change is to fullscreen or just a window size change.
