Bitmap fonts / Custom font issues with the docking branch

[samhocevar]

I am using custom bitmap fonts instead of using the TTF engine. There are three major reasons for using bitmap fonts:

• animated fonts
• colour fonts
• animated colour fonts

However, with the docking branch, I cannot seem to properly override the default font using PushFont(). Here is what happens:

• the default font is still used for windows/tab titles
• the application randomly crashes when playing around with the dock: ../../imgui_draw.cpp:1177: void ImDrawList::AddText(const ImFont*, float, const ImVec2&, ImU32, const char*, const char*, float, const ImVec4*): Assertion `font->ContainerAtlas->TexID == _TextureIdStack.back()' failed.

Maybe I am doing something wrong, since custom fonts are not really documented and I know the API has a lot of legacy… but that code used to work perfectly without docking.

Here is a patch that modifies example_sdl_opengl3 to demonstrate the two problems above : patch-bitmap-font-test.diff.txt

Below is the font creation part if you have any comments on it:

static ImWchar const ranges[] = { 0x20, 0x7f, 0 };

ImFontAtlas *atlas = IM_NEW(ImFontAtlas)();
atlas->TexWidth = 128;
atlas->TexHeight = 128;
atlas->TexUvScale = ImVec2(1.f / 128, 1.f / 128);

ImFontConfig config;
config.FontData = malloc(1);
config.FontDataSize = 1;
config.FontDataOwnedByAtlas = false;
config.SizePixels = 8;
config.GlyphRanges = ranges;
ImFont *font = atlas->AddFont(&config);

// Operations copied from ImFontAtlasBuildSetupFont()
font->FontSize = config.SizePixels;
font->ConfigData = &atlas->ConfigData[0];
font->ContainerAtlas = atlas;
font->Ascent = 0;
font->Descent = config.SizePixels;
font->ConfigDataCount++;

// Add some glyphs from a hypothetical regular grid
for (int ch = 0x20; ch < 0x80; ++ch)
{
    font->AddGlyph(ch, 0, 0, 6, 8, (ch % 0x10) * 8.f / 128, (ch / 0x10) * 8.f / 128, (ch % 0x10 + 1) * 8.f / 128, (ch / 0x10 + 1) * 8.f / 128, 6);
}
font->BuildLookupTable();

[ocornut]

Thanks for your report Sam.

the default font is still used for windows/tab titles
the application randomly crashes when playing around with the dock:

I'll have to look in more details, but I think both issues would be mitigated if you passed your atlas to the ImGui::CreateContext() call so your atlas and your font becomes the default font. Is that what you did in your actual application?

(In particular, when merging two windows together in the docking branch, the "host" window is created in NewFrame() using the default font. Which can be slightly problematic, but my solutions for it currently have other issues.)

[samhocevar]

I remember all sort of weird things happening if I used my custom atlas in ImGui::CreateContext() but that wasn’t with a minimal repro case, so I’ll double check!

[ocornut]

I kept this open in spite of being so old (and probably not relevant to you anymore) as it presented a case that I eventually wanted to facilitate.

Ongoing work on WIP branch dynamic_fonts aimed to be merged for 1.92 (#8465) should make it easier.

The expected approach for this particular use case would likely be to create your own ImFontLoader and assign this to a ImFontConfig. Issue #8466 shows a basic example of creating a "procedural" fonts were dummy glyphs are loaded on demand:

Except ImFontLoader is currently still in imgui_internal.h. I suppose as we battle-test other features toward 1.92, we might decide how far we want to go with making this a public API. But I imagine if that API changes it's not going to be much.

The specific assert you stumbled on doesn't exist anymore with the new code.

There are likely other issues with loading bitmap fonts, but given this is 2018 and the code is going to massively change, I suggest that people interested in this open new issues.

The new design for textures means that you could in theory also create independent ImTextureData instances and feed them to the renderer backend, making it possible to create textures in a backend-agnostic manner. There are probably a few missing steps in order to make this possible effortlessly. Not thing that's technically undefined is how io.Textures[] is repopulated by EndFrame(). So right you could append your texture to that array after EndFrame(), but you'd need to do it every frame. We'll probably clarify this over time.