Problem with `PushFont` and `PopFont` with menus

[voidware]

Version/Branch of Dear ImGui:

1.90

Back-ends:

all

Compiler, OS:

Windows

Full config/build information:

No response

Details:

I would like to have a Menu in one font and items within it in another.

If you push a font in order to have a BeginMenu in a different font, but then want some MenuItem in the normal (default) font and call PopFont it will assert fail because the font stack is wrong - unless you manually fix the font stack with a hack.

asserts here in AddText

    IM_ASSERT(font->ContainerAtlas->TexID == _CmdHeader.TextureId);  // Use high-level ImGui::PushFont() or low-level ImDrawList::PushTextureId() to change font.

Code example with hackaround:

struct PushIconFont
{
    // class to push and pop the icon font
    bool        _pushed = false;

    void        push()
    {
         ImGui::PushFont(iconFont);
         _pushed = true;
    }

    void        pop()
    {
        if (_pushed)
        {
            ImGui::PopFont();
            _pushed = false;
        }
    }

    static void fixme()
    {
        // XXX big hairy steaming great hack !!
        auto w = ImGui::GetCurrentWindow();
        int z = w->DrawList->_TextureIdStack.Size;
        if (!z)
        {
            auto font = ImGui::GetDefaultFont();
            w->DrawList->PushTextureID(font->ContainerAtlas->TexID);
        }
    }

    PushIconFont()  { push(); }
    ~PushIconFont()  { pop(); }
};

if (ImGui::BeginMenuBar())
 {
     // push the icon font.
     PushIconFont pf;

     // make a menu using the icon font
     if (ImGui::BeginMenu(ICON_MD_MORE_HORIZ)) // three dots "..."
     {
         // we now want some menu items in the default font
         pf.pop(); // pop off the icon font

         // this fixes the stack imbalance so we can use the base font
         // XXX THIS IS A STEAMING HACK !!
         pf.fixme();

         // !! BANG the following line will asset fail unless
         // `fixme` is done above.

         // make some normal menu items
         if (ImGui::MenuItem("Something")) doSomething();
         if (ImGui::MenuItem("Something else")) doSomethingElse();

         ImGui::EndMenu();            
     }

     ImGui::EndMenuBar();    
 }

The above code has a Steaming Great Hack in fixme to do this.

I can explain what is happening:

1. PushFont is called which pushes onto g.FontStack and PushTextureID pushes onto the drawlist TextureIdStack. So we're on both stacks.

2. BeginMenu is cool until you click on it. It creates a popup which calls Begin. Begin ascertains we're first_begin_of_the_frame and calls window->DrawList->_ResetForNewFrame() which clears the TextureIdStack.

But hey, the g.FontStack is still pushed!

The workaround is to pop as normal (which has the side-effect of popping the TextureIdStack to NULL) then manually pushing it back in fixme. Bluh!

Is this an ImGui bug, perhaps a limitation or have i gone mad (again) ?

Thanks.

Screenshots/Video:

No response

Minimal, Complete and Verifiable Example code:

// Here's some code anyone can copy and paste to reproduce your issue
ImGui::Begin("Example Bug");
MoreCodeToExplainMyIssue();
ImGui::End();

[ocornut]

I believe this is the same as #3224, #6398, 5529

[voidware]

Yes, it does look like the same problem. Thanks for pointing that out.

Although wanting to push and pop the font across Begin seems like a bigger ask than just changing the font within menus of the same window. But it turns out the latter is actually doing the same thing due to popups.

Turns out i changed my menu now so I don't actually need this fix (or my hack). So maybe low priority anyway.

Thanks.

[voidware]

As an aside, i noticed there are places where PushTextureID is called internally to ensure the stack is non-empty rather than as push/pop pairs;

eg.

static ImDrawList* GetViewportBgFgDrawList(ImGuiViewportP* viewport, size_t drawlist_no, const char* drawlist_name)
{
...
        draw_list->_ResetForNewFrame();
        draw_list->PushTextureID(g.IO.Fonts->TexID);
...
}

and

bool ImGui::Begin(const char* name, bool* p_open, ImGuiWindowFlags flags)
{
...
        // Setup draw list and outer clipping rectangle
        IM_ASSERT(window->DrawList->CmdBuffer.Size == 1 && window->DrawList->CmdBuffer[0].ElemCount == 0);
        window->DrawList->PushTextureID(g.Font->ContainerAtlas->TexID);
...
}

So a "fix" could be an internal version of my workaround to ensure the texture ID stack is not empty. It might fix the other problems too.

Just an idea.

[ocornut]

I have pushed a fix for this: eb7201b

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