Using PushFont/PopFont() right before and after Begin() will break rendering for window draw list objects

[EricPlayZ]

Version/Branch of Dear ImGui:

Version: 1.89.5
Branch: master

Back-end/Renderer/Compiler/OS

Back-ends: imgui_impl_dx11.cpp + imgui_impl_win32.cpp
Compiler: MSVC
Operating System: Windows 11

My Issue:

When using PushFont() before Begin() and then using PopFont() right after Begin() and then trying to render a window draw list object, the object fails to render (it simply doesn't render). This happens only to some, for example I can render a button but the border does not seem to render, or I can render an image but the border does not render.
If I move PopFont() after my window render list object, it seems to render fine.

I have my own functions for rendering a window, I've verified that the issue has nothing to do with my custom styles either, I've tried using the original Begin/End() functions and the exact same thing happens. If I remove the PushFont/PopFont() functions from before and after Begin(), window draw list objects render fine. The font of the custom styles are also all valid as the titlebar of my window displays all text and everything fine.
I genuinely don't know why doing this affects drawing inside the window. If I get the background or foreground draw list, everything draws fine, obviously. Here's the snippet of code from the screenshots further below:

ImGuiEx::Window("test window", &app->windowOpen, &app->windowMinimized, windowExStyle, titleBarExStyle, mainWindowFlags, [&]() {
	ImGui::GetWindowDrawList()->AddRectFilled(ImVec2(0, 0), ImVec2(250, 250), ImGui::GetColorU32(ImGui::ColorConvertU32ToFloat4(IM_COL32(255, 0, 0, 255))), 1.0f, 0);
});

The reason why I'm even pushing the custom font is to make sure the window calculates titlebar sizes according to the specified font. This could very simply be solved by modifying Begin() to take in the custom font's size for the sizes that it needs to calculate using that instead of just pushing the entire font to stack, but I haven't gotten around to doing that yet, and I came across this issue while coding a custom widget, so I decided to open an issue as this does not seem like normal behavior to me, unless I'm missing something about the backend, or maybe it's intended.

Screenshots

Without pushing font (intended result):

With pushing font (what I'm currently getting):

Standalone, minimal, complete and verifiable example:

ImGui::PushFont(someFont);
ImGui::Begin("Example Bug");
ImGui::PopFont();
ImGui::GetWindowDrawList()->AddRectFilled(ImVec2(0, 0), ImVec2(250, 250), ImGui::GetColorU32(ImGui::ColorConvertU32ToFloat4(IM_COL32(255, 0, 0, 255))), 1.0f, 0);
// using PopFont() here instead would fix the issue, but I would like to not do that in case I have other widgets that use the current font on stack but also use the window draw list to draw things
ImGui::End();

[ocornut]

Hello,
Seem to be an open known issue, see #3224

[ocornut]

I have pushed a fix for this: eb7201b

Thanks for reporting!

Repro

// #6398
if (1)
{
    ImGui::PushFont(font2);
    ImGui::Begin("Example Bug");
    ImGui::PopFont();
    ImGui::Text("Hello");
    ImGui::ColorButton("button", ImVec4(1, 0, 0, 1));
    ImGui::End();
    //ImGui::PopFont();
}

(It's not a perfect fix, in theory our code and system are still rather broken for the case of using multiple atlases textures, but I don't think that has been fully exercised ever, so we'll address that when the time comes.)

[EricPlayZ]

Thank you, glad to see it's been fixed!