Memory leak when rendering with DX11 in C++ #7615

Closed
opened 2024-05-23 09:25:51 +00:00 by AlexHughesMGP · 0 comments
AlexHughesMGP commented 2024-05-23 09:25:51 +00:00 (Migrated from github.com)

Version/Branch of Dear ImGui:

Version 1.89.6, Branch: master

Back-ends:

imgui_impl_win32.cpp + imgui_impl_dx11.cpp

Compiler, OS:

Windows 10 + MSVC 14.39.33519

Full config/build information:

No response

Details:

My Issue/Question:

I am using Dear ImGui with the win32 and dx11 backends in a fairly complicated control panel application, and it appears to be causing a memory leak. The code I'm using to render is straight from the demo:
image
Every frame, imgui_new_frame() is called, then our UI code, then imgui_dx11_render(). However, at a regular interval 32,903 bytes are allocated and never deallocated. In one test it was every ~8 seconds, and in another every ~700 milliseconds:
image
image
Line 215 is ImGui_ImplDX11_RenderDrawData(ImGui::GetDrawData());. I'm not able to post the full code because there are thousands of lines and it's confidential, so I understand that it may be difficult to help, but it would be helpful to know:

  1. Are there any common/obvious/possible mistakes to make between imgui_new_frame and imgui_dx11_render that could cause this?
  2. Is it possible/likely that the call stack provided by VS2022 is wrong or misleading, and that something else is at fault?
  3. Is there anything I can try to get more information on what's going on to help diagnose the issue?

It's very strange because the code works exactly like the example, and I doubt that Dear ImGui or DX11 have significant memory leaks like this. The fact that it happens at a consistent interval but not every frame also seems odd.

Screenshots/Video:

No response

Minimal, Complete and Verifiable Example code:

// Here's some code anyone can copy and paste to reproduce your issue
void imgui_new_frame() {
    if (g_ResizeWidth != 0 && g_ResizeHeight != 0)
    {
        CleanupRenderTarget();
        g_pSwapChain->ResizeBuffers(0, g_ResizeWidth, g_ResizeHeight, DXGI_FORMAT_UNKNOWN, 0);
        g_ResizeWidth = g_ResizeHeight = 0;
        CreateRenderTarget();
    }
    // Start the Dear ImGui frame
    ImGui_ImplDX11_NewFrame();
    ImGui_ImplWin32_NewFrame();
    ImGui::NewFrame();
}

void imgui_dx11_render() {
    ImVec4 clear_color = ImVec4(0.0f, 0.0f, 0.00f, 1.00f);
    // Rendering
    ImGui::Render();
    const float clear_color_with_alpha[4] = { clear_color.x * clear_color.w, clear_color.y * clear_color.w, clear_color.z * clear_color.w, clear_color.w };
    g_pd3dDeviceContext->OMSetRenderTargets(1, &g_mainRenderTargetView, nullptr);
    g_pd3dDeviceContext->ClearRenderTargetView(g_mainRenderTargetView, clear_color_with_alpha);
    ImGui_ImplDX11_RenderDrawData(ImGui::GetDrawData());
    g_pSwapChain->Present(1, 0);
}

imgui_new_frame();
state.update(target_seconds_per_frame);    
imgui_dx11_render();
### Version/Branch of Dear ImGui: Version 1.89.6, Branch: master ### Back-ends: imgui_impl_win32.cpp + imgui_impl_dx11.cpp ### Compiler, OS: Windows 10 + MSVC 14.39.33519 ### Full config/build information: _No response_ ### Details: **My Issue/Question:** I am using Dear ImGui with the win32 and dx11 backends in a fairly complicated control panel application, and it appears to be causing a memory leak. The code I'm using to render is straight from the demo: ![image](https://github.com/ocornut/imgui/assets/146079787/98b0740c-3d91-4e27-a064-7500827ab0a2) Every frame, imgui_new_frame() is called, then our UI code, then imgui_dx11_render(). However, at a regular interval 32,903 bytes are allocated and never deallocated. In one test it was every ~8 seconds, and in another every ~700 milliseconds: ![image](https://github.com/ocornut/imgui/assets/146079787/68eff42a-a882-4722-a74f-d5a02547de86) ![image](https://github.com/ocornut/imgui/assets/146079787/88305abf-084d-484f-bcf4-ff354e99a910) Line 215 is `ImGui_ImplDX11_RenderDrawData(ImGui::GetDrawData());`. I'm not able to post the full code because there are thousands of lines and it's confidential, so I understand that it may be difficult to help, but it would be helpful to know: 1) Are there any common/obvious/possible mistakes to make between imgui_new_frame and imgui_dx11_render that could cause this? 2) Is it possible/likely that the call stack provided by VS2022 is wrong or misleading, and that something else is at fault? 3) Is there anything I can try to get more information on what's going on to help diagnose the issue? It's very strange because the code works exactly like the example, and I doubt that Dear ImGui or DX11 have significant memory leaks like this. The fact that it happens at a consistent interval but not every frame also seems odd. ### Screenshots/Video: _No response_ ### Minimal, Complete and Verifiable Example code: ```cpp // Here's some code anyone can copy and paste to reproduce your issue void imgui_new_frame() { if (g_ResizeWidth != 0 && g_ResizeHeight != 0) { CleanupRenderTarget(); g_pSwapChain->ResizeBuffers(0, g_ResizeWidth, g_ResizeHeight, DXGI_FORMAT_UNKNOWN, 0); g_ResizeWidth = g_ResizeHeight = 0; CreateRenderTarget(); } // Start the Dear ImGui frame ImGui_ImplDX11_NewFrame(); ImGui_ImplWin32_NewFrame(); ImGui::NewFrame(); } void imgui_dx11_render() { ImVec4 clear_color = ImVec4(0.0f, 0.0f, 0.00f, 1.00f); // Rendering ImGui::Render(); const float clear_color_with_alpha[4] = { clear_color.x * clear_color.w, clear_color.y * clear_color.w, clear_color.z * clear_color.w, clear_color.w }; g_pd3dDeviceContext->OMSetRenderTargets(1, &g_mainRenderTargetView, nullptr); g_pd3dDeviceContext->ClearRenderTargetView(g_mainRenderTargetView, clear_color_with_alpha); ImGui_ImplDX11_RenderDrawData(ImGui::GetDrawData()); g_pSwapChain->Present(1, 0); } imgui_new_frame(); state.update(target_seconds_per_frame); imgui_dx11_render(); ```
Sign in to join this conversation.
No milestone
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
ocornut/imgui#7615
No description provided.