[Bug]: ImFontConfig not initialized correctly

[eyalzus12]

Pre-submission Checklist

• I have read the FAQ Wiki
• I have searched existing issues and this is not a duplicate
• I am using the latest version of Hexa.NET.ImGui

Hexa.NET.ImGui Version

2.2.9

Bug Description

ImFontConfig is initialized with all fields being 0, null, or otherwise default.

However, this is not correct, and attempting to use an ImFontConfig created this way causes errors.

As per https://github.com/ocornut/imgui/blob/1bcc23ef123869240971427902b32109c8157e24/imgui_draw.cpp#L2418, the following values need to have different defaults:

1. FontDataOwnedByAtlas should default to true
2. ExtraSizeScale should default to 1 (currently not exposed?)
3. GlyphMaxAdvanceX should default to float.MaxValue
4. RasterizerMultiply should default to 1
5. RasterizerDensity should default to 1

Steps to Reproduce

1. Create a new ImFontConfig
2. Attempt to use it (for example, in AddFontFromMemoryTTF)
3. You will receive an error Assertion failed: font_cfg_in->RasterizerDensity > 0.0f && "Is ImFontConfig struct correctly initialized?"

Expected Behavior

The font is added and later rendered with no errors.

Code Sample

ImFontConfig config = new();
byte[] fontData = ...;
fixed (byte* fontDataPtr = fontData)
    ImGui.GetIO().Fonts.AddFontFromMemoryTTF(fontDataPtr, fontData.Length, 16, &config);

Platform

All

.NET Version

net9.0

Additional Context

After initializing the values to their current defaults, there are no further issues.

[JunaMeinhold]

Hi, that is not a bug. It cannot be fixed, this is a code generator limitation, you can however call the native constructor (ImGui.ImFontConfig()), but you have to free the memory afterwards.

[eyalzus12]

Then define an exception for it. Or atleast document that somewhere.

[JunaMeinhold]

I’ve already explained the technical limitation and shared a valid workaround. Your follow-up comment does not align with our Code of Conduct, particularly regarding respectful communication and pushy requests. This project is maintained on a volunteer basis, so please refrain from using this kind of language going forward.

And btw Dear ImGui already documents that, i just provide the wrapper and in general most c# wrappers if not all (with automatic generation) have this behavior too.

[sonoro1234]

Just in case it is not clear. (It seems to be not well documented)
This is a pattern used in LuaJIT-ImGui for constructors:

local ImFontConfig= {}
ImFontConfig.__index = ImFontConfig
function ImFontConfig.__new(ctype)
    local ptr = lib.ImFontConfig_ImFontConfig()
    return ffi.gc(ptr,lib.ImFontConfig_destroy)
end
M.ImFontConfig = ffi.metatype("ImFontConfig",ImFontConfig)

So that when a struct function is a constructor there is always a destructor: StructName_destroy that can be called. For what I have seen in C# that should be called from the Class finalizer

[JunaMeinhold]

@sonoro1234 Hi, I'm aware of that, I use it already here: https://github.com/HexaEngine/Hexa.NET.ImGui/blob/main/Hexa.NET.ImGui%2FUtilities%2FImGuiFontBuilder.cs#L121

One useful thing would be placement new constructors so that the user can decide to stack alloc or heap alloc.

void TypeCtor(Type* mem, args...)
{
      new(mem) Type(args...);
}

[sonoro1234]

One useful thing would be placement new constructors so that the user can decide to stack alloc or heap alloc.

If constructors option is used in generation a _Construct version is added:

CIMGUI_API ImFontConfig* ImFontConfig_ImFontConfig(void)
{
    return IM_NEW(ImFontConfig)();
}
CIMGUI_API void ImFontConfig_ImFontConfig_Construct(ImFontConfig* self)
{
    IM_PLACEMENT_NEW(self)ImFontConfig();
}
CIMGUI_API void ImFontConfig_destroy(ImFontConfig* self)
{
    IM_DELETE(self);
}

[JunaMeinhold]

One useful thing would be placement new constructors so that the user can decide to stack alloc or heap alloc.

If constructors option is used in generation a _Construct version is added:

CIMGUI_API ImFontConfig* ImFontConfig_ImFontConfig(void)
{
    return IM_NEW(ImFontConfig)();
}
CIMGUI_API void ImFontConfig_ImFontConfig_Construct(ImFontConfig* self)
{
    IM_PLACEMENT_NEW(self)ImFontConfig();
}
CIMGUI_API void ImFontConfig_destroy(ImFontConfig* self)
{
    IM_DELETE(self);
}

Thanks for the info i overlooked that. But i can't integrate that at the moment anyways because of the PR #106

[eyalzus12]

Sorry for my response, I was venting frustration over a long day of debugging. My bad.

And btw Dear ImGui already documents that

I don't understand what you mean by that? In imgui's ImFontConfig's default constructor those properties are set. What would there be to document?

I think a simple "don't use this constructor, call this function instead" comment would have helped me a lot.

[JunaMeinhold]

Sorry for my response, I was venting frustration over a long day of debugging. My bad.

And btw Dear ImGui already documents that

I don't understand what you mean by that? In imgui's ImFontConfig's default constructor those properties are set. What would there be to document?

I think a simple "don't use this constructor, call this function instead" comment would have helped me a lot.

No issue. What i meant with that imgui documents it was the assert. And sadly i can't just add a comment in those files, they are auto generated and at the moment the code gen doesn't allow injecting comments (the legacy generator) so it's blocked until PR #106 is done

[eyalzus12]

I see. Thank you! Should i close this issue or keep it open to it can be dealt with once #106 is done?