ocornut / imgui

Dear ImGui: Bloat-free Graphical User interface for C++ with minimal dependencies
MIT License
61.45k stars 10.34k forks source link

IM_ASSERT(font->ContainerAtlas->TexID == _CmdHeader.TextureId); #8080

Open Nanokoli opened 1 month ago

Nanokoli commented 1 month ago

Version/Branch of Dear ImGui:

Branch: docking

Back-ends:

imgui_impl_XXX.cpp + imgui_impl_XXX.cpp

Compiler, OS:

win

Full config/build information:

Not

Details:

static ImDrawList GetViewportBgFgDrawList(ImGuiViewportP viewport, size_t drawlist_no, const char* drawlist_name)

This function may not get the correct TexID And Will case IM_ASSERT(font->ContainerAtlas->TexID == _CmdHeader.TextureId);

The function Get g.IO.Fonts->TexID directly,But I thought may It try to get the DefaultFont->ContainerAtlas->TexID instead of g.IO.Fonts->TexID

This assert occurs when DefaultFont does not belong to g.IO.Fonts

Screenshots/Video:

image

Minimal, Complete and Verifiable Example code:

Make g.IO.Fonts->TexID!=g.IO.FontDefault->ContainerAtlas->TexID And run docking branch

ocornut commented 1 month ago

This assert occurs when DefaultFont does not belong to g.IO.Fonts

Why doesn't DefaultFont belong to g.IO.Fonts[] ? That doesn't seem correct in the first place.

Nanokoli commented 1 month ago

This assert occurs when DefaultFont does not belong to g.IO.Fonts

Why doesn't DefaultFont belong to g.IO.Fonts[] ? That doesn't seem correct in the first place.

When you create a own ImFontAtlas,i create own ImFontAtlas in my async font loader,when font's load finished Change the DefaultFont dirctly

ocornut commented 2 weeks ago

I don't think we can fully support this.

The same issue would happen if you called GetWindowDrawList()->AddText(...) with a font that's not in the current atlas.

Among other things, draw list functions are pulling from _Data->TexUvWhitePixel and _Data->TexUvLines[] which are technically atlas dependent. I believe some people have been, by sheer luck, taking advantage of the fact that with similar setting the values for those UV coordinates are going to be the same between two atlas. I am going to have to keep this use case in mind, because we want to be supporting multiple atlas, but it may needs an explicit call to change atlas.

However, the good news is that I think in 1-2 months the font building will be incremental/on-demand, so perhaps you will not need to setup async loading.

As part of the work I am doing for that, I am forced to work on a system where the atlas will be automatically bound, so this assert won't exist anymore:

IM_ASSERT(font->ContainerAtlas->TexData == _CmdHeader.Texture._TexData);  

Will be replaced by something like:

if (font->ContainerAtlas->TexData != _CmdHeader.Texture._TexData) 
   _SetTexture(font->ContainerAtlas->TexID);

But whereas "font->ContainerAtlas" works for AddText() for other functions it would need to pull it from the ImDrawListSharedData instance. So what I could do is add a call to explicit bind another font atlas but that will work with the future code, not with the current one.

If you manually call draw_list->_SetTextureID(....) before draw_list->AddText() you can work around it.