I'm creating two swap chains on my device so I can render to two separate views. My engine is in c++ and I'm housing the rendering in controls within a c# front end. At the moment I have two panels, each showing a different scene. One of them takes longer to render than the other one.

I create my device with a backbuffer that is the full size of the screen. This means I can resize my views freely and not worry about losing the device.

I'm seeing some strange artifacts which I think is because one of them take longer to render than the other, even though I call render1() and render2() consecutively in the same thread. If I put a 20 ms thread sleep in between these calls, it renders fine

Could this be because the CPU has sent everything to the GPU for render1() and when render2() starts, the GPU is still partway through rendering view 1? If so, is there a way for the CPU to wait until the Present on the swap chain has actually finished with the shared back buffer?

I'm creating two swap chains on my device so I can render to two separate views. ... At the moment I have two panels, each showing a different scene.

Can you be a bit more precise by what you mean by "view" and "panel?" And why you're using two swapchains? Do you, perhaps, mean 2 separate viewports?

Thanks guys, it would appear my understanding of how this works is limited.

#1: Stop misunderstanding that and implement things correctly instead of using work-around hacks. This will solve all of your problems immediately.

Using a work-around hack is not what I was trying to do and, in fact, that's kind of a contradiction - if I've misunderstood something, it's not really a work-around hack. My c# application is a multi 'view' (by view I mean a panel/control in c# that can display a rendered image from within my c++ engine) app with at least 3 rendered panels, but the option of more. The reason I initially thought to use swap chains is purely by research. Once I'd got my image rendering in a view in my c# client, I resized it and the pixels stretched which I obviously don't want. When I did some further research, I found that you needed to reset the device when changing the size of the rendering area in order that it didn't have to stretch the image across a wider area. Resetting the device, in my mind, meant losing, or decoupling then, my resources. As I have a fair amount loaded into the card and I'd seen other applications manage to resize windows dynamically, I assumed they couldn't be resetting the device and reloading resources constantly whilst the window was resizing, which led me to swap chains.

I read that in order to use swap chains (which at this point felt like the right thing to) I need to render to a back buffer retrieved using the swap chain (which I thought was its own back buffer) created for the view/rendering panel/viewport and then once rendering is done, call Present on that swap chain. What I wasn't aware of is that any additional swap chain created uses the same back buffer. L Spiro, you mentioned that swap chains have their own back buffers - is that by default because it appears that any additional swap chain I create, uses the same back buffer as the device - which does make sense if the idea is that you are rendering to a specified portion of the back buffer - and that would explain the artifacts I am seeing where one rendered view shows flickering bits of the other and vice versa.

So, seeing as I have clearly been mislead by my research or have misunderstood it, let me see if I now understand...:

In my c++ engine, I have the ability to render in full screen mode, windowed mode or to render to a passed-in HWND. I need to create a C# front end which has multiple 'views' in the form of a couple of split containers (front, side, top - style) which will all be rendering the same scene but from different angles. I also need to cater for a floating tool-like window which could very well be floating over the other rendered views.

So from Buckeye's point, I can achieve this by just using the default SwapChain that gets created when creating the device and Presenting to different areas of it (passing in the correct RECT structures to Present()). If I need to have windows floating over the top, I guess I just render them after the ones underneath?

#2: Stop running away from lost devices. The full list of things that can cause the device to be lost is intentionally left unspecified so that people don’t make assumptions as to what can cause it and thus will implement proper handling of such a scenario. It is also trivial to restore resources after a lost device, so there is really no reason not to handle it properly.

I'm not running away from anything. My assumption on this was one of speed after a bit of misled research. Other apps that do this resizing of multiple views can't possibly be resetting and reloading resources dynamically anytime the mouse is moving whilst resizing - I just took the wrong route to working out how that's done.

Thanks

Just to reiterate, the importance of using technical terms to describe a technical problem cannot be overemphasized

I've worked in the IT industry for 23 years and one of the things that has always bothered me is issues or bugs that are not described properly so I'm disappointed I didn't get my point across well enough. Sorry for that, I'm not intending anyone to 'guess' parts of my issue, I thought I'd covered everything.

I've moved on from the additional swapchains after your comments and I'm now trying to render using viewports. In simplistic terms and removing C# from the equation, I'm rendering to two viewports (DirectX9 viewports). One on the left and one on the right. When I call Present, I call it twice (once after the render to each viewport), not at the end. The reason I do this is because in my Present call, I'm using an HWND as the hDestWindowOverride parameter. I am supplying source and dest RECTs. The source for the left render is the left half of the back buffer and the source for the right is the right side. The destination RECT is effectively the local client area of the render 'frame', so 0, 0, width, height. Width being half the size of the back buffer.

Both viewports do render the correct views but the artefact is a shimmering/tearing band across the screen horizontally where, on the left, the band shows the contents of the right-hand render and, on the right, it shows the left side. It's difficult to explain but it looks like when I render each view, the previous view hasn't quite finished rendering so I'm getting a form of tearing. It looks like when I've rendered the left side, I start on the right side and the CPU has already called Present on the next view before the previous view has been rendered. If I put a sleep call of 50ms or so before each call to render each frame, just to ensure the GPU would have fully rendered everything, it works perfectly (albeit at 20fps of course).

I had a look at the CodeSampler example for rendering to viewports and I'm doing exactly the same as they are other than the fact that I have to call Present after each BeginScene/EndScene rather than at the end (in their example, they call Present with all NULL parameters).

Edit: I think this is the problem. Calling Present() after rendering one view is swapping the back buffer and the front buffer when I should be calling present after rendering both views. This would work if I wasn't using HWNDs supplied from C#. This is why I went down the additional swap chain route as each one will have its own backbuffer and it won't matter the order in which I call Present...

It's still not clear exactly what you're doing.