Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
Nanokoli opened this issue Oct 20, 2024 · 3 comments
Open

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

Nanokoli opened this issue Oct 20, 2024 · 3 comments

Comments

@Nanokoli
Copy link

Nanokoli commented Oct 20, 2024

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
Copy link
Owner

ocornut commented Oct 22, 2024

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
Copy link
Author

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
Copy link
Owner

ocornut commented Nov 8, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants