
About how the memory flowed, but I could not understand why
Hello, dear habracheloveki.
In this short post, I want to share with you some points that I encountered while developing one of my applications (reader for Windows). It's about DirectX and, it seemed to me, strange memory leaks.
To display the contents of the pages, I decided to use DirectX. The idea was simple: first I create a 2D texture with text, and then I display a 3D model using previously prepared textures. This gives me the ability to do 3D page turning animations.
Something like this:

At the time of the release of the application to the store, I expected universal admiration. But it was not there. Users were dissatisfied. Analysis of the situation showed that memory is flowing. And it flows very well. But why? This I could not understand for a long time.
Given the fact that applications in Windows 8.1 and Windows Phone 8.1 are not completely unloaded during the “close”, memory leaks accumulated.
The process of finding a leak was not at all interesting. But the result seemed strange to me.
The following objects are used to display one frame of a 3D scene:
Further, somewhere in the scene display method, we will use something like this code:
Resources must be freed. And here lurks one of the problems that caused this post.
Just write:
not enough. At m_d3dContext somewhere inside there are links to render-target and depth buffer.
Those. we need to indicate nothing to our context as a goal.
The trouble is that we get a memory leak if we do like this:
To correct the situation, just change the order of the instructions:
This is the first "oddity" that I do not understand. I will be glad if someone tells why this happens.
The second "oddity" is related to textures. Or rather with shader resources.
The fact is that if we do like this:
That should do so:
Otherwise, the texture will not be released, even if you “delete” it.
In other words, before removing (release) shader resources, they must be freed (unbind).
In principle, after realizing the first “strangeness”, the second does not seem to be such anymore.
Nevertheless, this did not seem obvious to me.
PS: Now the problem with memory leak is fixed and the anger of users is gradually changing to mercy.
In this short post, I want to share with you some points that I encountered while developing one of my applications (reader for Windows). It's about DirectX and, it seemed to me, strange memory leaks.
How did I create a problem for myself?
To display the contents of the pages, I decided to use DirectX. The idea was simple: first I create a 2D texture with text, and then I display a 3D model using previously prepared textures. This gives me the ability to do 3D page turning animations.
Something like this:

At the time of the release of the application to the store, I expected universal admiration. But it was not there. Users were dissatisfied. Analysis of the situation showed that memory is flowing. And it flows very well. But why? This I could not understand for a long time.
Given the fact that applications in Windows 8.1 and Windows Phone 8.1 are not completely unloaded during the “close”, memory leaks accumulated.
The process of finding a leak was not at all interesting. But the result seemed strange to me.
What seemed strange to me?
Releasing render-target resources (don't know how to translate) and depth buffer
The following objects are used to display one frame of a 3D scene:
Microsoft::WRL::ComPtr m_renderTargetView;
Microsoft::WRL::ComPtr m_depthStencilView;
Further, somewhere in the scene display method, we will use something like this code:
ID3D11RenderTargetView *const targets[1] = { m_renderTargetView.Get() };
m_d3dContext->OMSetRenderTargets(1, targets, m_depthStencilView.Get());
Resources must be freed. And here lurks one of the problems that caused this post.
Just write:
m_renderTargetView = nullptr;
m_depthStencilView = nullptr;
not enough. At m_d3dContext somewhere inside there are links to render-target and depth buffer.
Those. we need to indicate nothing to our context as a goal.
m_d3dContext->OMSetRenderTargets(0, nullptr, nullptr);
The trouble is that we get a memory leak if we do like this:
m_d3dContext->OMSetRenderTargets(0, nullptr, nullptr);
m_renderTargetView = nullptr;
m_depthStencilView = nullptr;
To correct the situation, just change the order of the instructions:
m_renderTargetView = nullptr;
m_depthStencilView = nullptr;
m_d3dContext->OMSetRenderTargets(0, nullptr, nullptr);
This is the first "oddity" that I do not understand. I will be glad if someone tells why this happens.
Texture Resource Release
The second "oddity" is related to textures. Or rather with shader resources.
The fact is that if we do like this:
Microsoft::WRL::ComPtr texture = ...
m_d3dContext->PSSetShaderResources(0, 1, &texture);
That should do so:
ID3D11ShaderResourceView* empty = NULL;
d3dContext->PSSetShaderResources(0, 1, &empty);
Otherwise, the texture will not be released, even if you “delete” it.
texture = nullptr;
In other words, before removing (release) shader resources, they must be freed (unbind).
In principle, after realizing the first “strangeness”, the second does not seem to be such anymore.
Nevertheless, this did not seem obvious to me.
PS: Now the problem with memory leak is fixed and the anger of users is gradually changing to mercy.