After Present i call doResize.
Why? Do you really need to change the buffer size (or check if it needs to be changed) every frame?
Ok, third attempt: After Present if mRequestResize is true i call doResize.
After Present i call doResize.
Why? Do you really need to change the buffer size (or check if it needs to be changed) every frame?
Ok, third attempt: After Present if mRequestResize is true i call doResize.
Hello L. Spiro
The leak was hidden, if i move back to instantly resizing it crashes again. I dont know what i can release more, i have the following:
-> release render target view
-> no reference to the Texture2D of the backbuffer is held
-> all shader resource views are released
-> depth buffer view is released
-> depth buffer texture is released
-> ClearState is called
Not released are:
-> 1 Vertex & 1 Pixel shader
-> the Texture2D object in the textures (the view is recreated after resize)
-> depth stencil states
-> blend states
-> rasterizer states
-> sampler states
-> 1 Vertex buffer
-> 1 Index buffer
-> 1 Input layout
Greetings
Plerion
A little updated:
Ive switched back to the one resize per frame approach and did a reportliveobjects at entersizemove and exitsizemove. This is what i get after resizing the window for over a minute (several thousand frames):
The only thing odd are the 4500 references on the pixel shader. But the amount of objects seems reasonable.
I had a similar issue with resizing my backbuffer on D3D11, perhaps its the same thing. Does it only occur when you click and drag to resize your window?
Here's a little test to check if it's the same problem I had:
1. Open task manager in windows and go to the Performance tab, make you sure can see the current memory committed (e.g. 3.5/12GB or whatever it happens to be).
2. Run your app and click and hold to resize the window, slowly move the mouse around without releasing the button and watch the commit amount in task manager. As you move the mouse around, the commit amount should steadily climb a few GB quite rapidly until your app crashes with E_OUTOFMEMORY.
3. Run your app again, this time click and hold to resize the window less than required to crash it, but enough to increase the commit, while watching the memory commit amount, then release the mouse button. When you release the button the commit amount should drop back to where it began, roughly.
If it's the same thing let me know and i'll write a longer post about what was causing it for me.