Swap Chains

1) It's not. I think I saw someone doing this once... I can't imagine why. You want the swap chain to be the size of the window. If it's not then either you're going to stretch a big image down to your window size, or you're going to be wasting memory with pixels outside your viewport size. Destroying and creating swapchains is fast, so avoiding having to destroy and recreate them is silly. nVidia does recommend allocating all your render targets first, and allocating a huge buffer would definately ensure it's allocated early and never again. On the other hand, an app with resizable windows is likely a tool, not a game, and the marginal speed improvement you may see isn't worth the wasted video memory. You're also not playing nicely with other applications if you're hogging all my video memory.

2) Since each swap chain may be a different size, you need a matching depth buffer. If two windows happen to be identical sizes you could share the depth buffer (and swap chain, and just present to a different window), but that's so rarely going to be the case in general that it may not be worth detecting, unless you're forcing specific window layouts and sizes.

So what would happen, if you sized the swap chain to the window client area and did not destroy and recreate the Swap chain upon a window resize event?
And another question. Whatever would happen, could I prevent it by initializing the swap chain with the whole Desktop size?

Thanks again!

By default it would stretch the rendered scene to fill the window. Grab my swapchain example (in the useful threads page), and remove the window resize handling. It doesn't specifically handle resizing just the swapchain window, but instead resets the entire device, but you can remove that to see what happens. Change the default backbuffer size to something small like 32x32 or 64x64, and make the window big. You'll see what sort of effect is has.

When using a full screen swap chain, you've got two main options.

1) Default (using Present with no rect). You draw a ton of data, filling the fullscreen backbuffer, then stretch it to your smaller window size. The will result in lower than optimal FPS (because of the extra wasted fillrate required, and because of the extra stetchblit step required), and higher memory usage.

2) Looks normal. Use SetViewport to draw to only a window sized portion of the buffer, then Present with a subrect the same as the viewport. There may be a small FPS hit in presenting a subrect. You're wasting memory.