   [SlimDX] Why does this (seem to) work?
  Yesterday, during an 'enthusiastic' coding session, I wrote a Direct3D / SlimDX application which I've since thought about a little more and am confused why it appear to works.Basically, I wanted a simple wrapper which would allow for SlimDX to draw to any particular window (HWND). I figured I'd  use a single, shared dynamically sized swap chain - if the window passed is bigger than the swap chain, it will be resized before being used. If the window is smaller, it will be clipped. I use the SwapChain.Present overload that allows the window handle to be specified.So, I'm using one swap chain (with a single back buffer) on multiple windows. But, if I'm using a swap chain with only two buffers then surely the 'back buffer' for the current window will be the 'front buffer' of the previous window? In which case, the previous window would be inadvertently redrawn?I don't see why this works, but it does. However, I'm only clearing the buffer to a specific colour at the moment so perhaps there isn't enough happening for me to notice the change? Or perhaps my understanding of buffer swapping is incorrect?Any enlightenment would be welcomed! :p   
  No insights?I can understand if the front buffer is copied to the window surface (in effect, painted on - blitted), but I didn't think it works like that.Can someone at least confirm whether or not this is normal behaviour?Thanks   ;  (hi again).Honestly, I can't give you much of insight. But I'm very interested if your approach actually works. Did you actually manage to draw something without glitches (for instance multiple views of your scene) ?There's a recent thread going on about swap chains, and one thing that caught my eye was that multiple swapchains for multiple windows is not the recommended way (just citing) without saying how to do so. Obviously your approach looks like that - if it works.And I was thinking about something similar if I ever have the need for multiple windows. Why use several swapchains - and waste memory if I understand it correctly - if Present can be redirected to any window anyway ?The one thing I managed to do though is to get rid of the reset logic (DX9) when resizing the window if I use a backbuffer with desktop size (i.e. big enough for any window size) and just set the viewport/transformations accordingly. So it is actually possible to resize without a swapchain recretion / device reset, something that would be essential for a Windows GUI with several views. But I did not investigate further because I have other interests now (setting up a component entity system and finally glueing my fragmented code to something more sensible).But anyway, I have one question, if I may ask: When do you render ? Is it triggered with a WM_PAINT ? Or still with the "real-time" endless while approach ?Edit: I just realized that you probably use DirectX 10 or 11. So I am even less of help, I use DX9 and will stick to it (doing 2D), sorry. This seems more like DX10/11 question than SlimDX anyway.[Edited by - unbird on June 3, 2010 7:35:31 PM];  I appears to work absolutely fine. No graphical glitches whatsoever. I was always under the impression that two buffers were used in a typical swap chain - the 'front' buffer is what is displayed in the target window (HWND). If you alter the front buffer, the user will see these changes happening. To get around this, the second buffer - the back buffer is drawn to instead and then flipped to the front on 'Present'. What I'm seeing so far suggests this isn't actually the case. I'm not doing anything else particularly fancy - this is a WinForms, not WPF application. It's Direct3D 9. I did wonder if it's due to me using Direct3D 9 (an Ex device) on a Windows 7 machine. Perhaps the new WDDM model alters the way these buffers work?Thanks for your input.   ;  You've just beaten my edit.[smile]Ahhh, DirectX 9. Good, here I'm with Windows XP.Quote:I was always under the impression that two buffers were used in a typical swap chain - the 'front' buffer is what is displayed in the target window (HWND). If you alter the front buffer, the user will see these changes happeningYou mean a sort of see-through effect. I know there's some way to do this for video display (hardware streaming video ?) but for Direct3D rendering ? My guts tells me that this maybe can happen in a fullscreen mode but in a windowed context the Present will blit anyway. As stated, I don't know that details of DirectX, especially this interoperation with Windows. And from the docs I'm rather confused in this regard (*)But if you could provide a downloadable executable I'd volunteer to test it on XP.(*) When something like this happens, I rather try combining flags/settings than further reading. If something works, it works. Yeah, on my machine! Does it work in every setting ? On "every" Windows ? With every hardware/driver ? Who knows before you actually try!;  I'm not sure about it, but i guess it works because of the window buffer. In fullscreen mode the frontbuffer is directly sent to the graphics card, but in window mode there is an extra buffer (one for the whole screen in XP, and one for each App in Vista and Win7) to make sure that window contents need only to be redrawn as they change. I guess that upon presenting the scene (and flipping the bufferes) the window and it's window buffer get refreshed with the current content of the frontbuffer. Thus you are able render multiple windows in a row with the same 2-layer swapchain, as long as the windows aren't refreshed inbetween. My guess is that it will lead to flickering if you drag a window across one of the render windows on XP (because it has only one buffer for the whole screen and needs to redraw the underlying window if something is dragged over it).   