imgui 1.92.0 ImTextureID

[Luksx]

with 1.92.0 imgui release there was a change in ImTextureID to ImTextureRef
Since this change, it does not build.

All API functions taking a ImTextureID parameter are now taking a 'ImTextureRef`:
ImTextureRef is a small composite structure which may be constructed from a ImTextureID (or constructed from a ImTextureData* which represent a texture which will generally be ready by the time of rendering).

[ChrisThrasher]

Ugh, ImGui keeps breaking their API at a fast pace. Is there any alternate solution that also lets ImGui-SFML support 1.91 or does supporting 1.92 necessarily require dropping support for older versions? I don’t want ImGui-SFML to be constantly raising it’s ImGui requirement to chase down these API breakages if we can help it.

[Luksx]

I just managed to get it working with replacing line 956
assert(io.Fonts->TexID != (ImTextureID) nullptr);
with
assert(io.Fonts->TexRef._TexData != nullptr);

Actually no clue why does it work xd

[TiphaineLAURENT]

I would guess it is possible (but probably not wanted) to use a macro to test the imgui version : https://github.com/ocornut/imgui/blob/v1.92.0/imgui.h#L31

#if IMGUI_VERSION_NUM >= 19200
    assert(io.Fonts->TexRef._TexData != nullptr); // You forgot to create and set font texture
#else
    assert(io.Fonts->TexID != (ImTextureID) nullptr); // You forgot to create and set font texture
#endif

[Romi-Brooks]

I just managed to get it working with replacing line 956 withassert(io.Fonts->TexID != (ImTextureID) nullptr); assert(io.Fonts->TexRef._TexData != nullptr);

Actually no clue why does it work xd

In ImGui v1.92.2b, an error occurs in imgui-SFML.cpp at line 1043:

const GLuint textureHandle = convertImTextureIDToGLTextureHandle(pcmd->TextureId);

Said that "'const struct ImDrawCmd' has no member named 'TextureId'"

use “const GLuint textureHandle = convertImTextureIDToGLTextureHandle(pcmd->GetTexID());”, for me ,it's works fine.

Perhaps we should revert to v1.91.1.

[fgallegosalido]

Ugh, ImGui keeps breaking their API at a fast pace. Is there any alternate solution that also lets ImGui-SFML support 1.91 or does supporting 1.92 necessarily require dropping support for older versions? I don’t want ImGui-SFML to be constantly raising it’s ImGui requirement to chase down these API breakages if we can help it.

Unfortunately, the ImGui mantainer really wants you to use the latest version possible. Although they break the API constantly, they normally allow some time to port to newer APIs by deprecating first. It's a constant effort, sure, but at the same time it forces users to update.

[majvax]

Hi! Are there plans to support Dear ImGui 1.92.0 in imgui-sfml?

Version 1.92.0 introduces several quality‑of‑life improvements for fonts, most notably dynamic fonts (add once, use at any size). This would be a great addition for SFML users, as it removes the need to pre-bake multiple sizes and improves text clarity at varying scales.

It would be awesome to have imgui-sfml adopt the new rendering/texture updates path (ImGuiBackendFlags_RendererHasTextures) so dynamic font sizing works out of the box.

see this link for reference

[ChrisThrasher]

If you want 1.92 support then please help me figure out what is the oldest version of ImGui that is still API-compatible with 1.92. I'm curious how far we have to raise our minimum requirement from 1.91.1 to support 1.92.

[majvax]

I'll perform tests later on my basic implementation, see #330 for reference.

[learn-more]

If you want 1.92 support then please help me figure out what is the oldest version of ImGui that is still API-compatible with 1.92. I'm curious how far we have to raise our minimum requirement from 1.91.1 to support 1.92.

Would it make sense to use the github builders for this?
With their matrix option you could probably do this reasonably well.

[majvax]

Unfortunately, 1.92.0 introduces breaking changes, as stated in the changelog.

As I understand it, you can use an old backend with the new ImGui version (e.g., use ImGui v1.92.0 with the current SFML backend for 1.91.1). What you can't do is use the new backend (one that supports all the new features of 1.92.0) with an old version of ImGui.

Conducting tests is, in my opinion, a waste of time since the changelog is very clear about this. I don't see the point of not upgrading imgui-sfml to support the new version.

Note: Currently, using ImGui 1.92.0 with the SFML backend for 1.91.1 doesn't work. I believe it's because the backend isn't up to date and uses deprecated functions. I haven't investigated this problem myself, since the fix has already been discussed. See this link for reference.

[ChrisThrasher]

Note: Currently, using ImGui 1.92.0 with the SFML backend for 1.91.1 doesn't work.

Yes, that is the entire point of this thread.

[majvax]

Note: Currently, using ImGui 1.92.0 with the SFML backend for 1.91.1 doesn't work.

Yes, that is the entire point of this thread.

Honestly, I’m not sure why supporting an obsolete version of ImGui is considered so important. The changelog is very clear about the breaking changes, and maintaining compatibility with outdated versions seems like unnecessary effort when the focus could be on supporting the latest releases.

[ChrisThrasher]

I would not call a <1 year old version of ImGui “obsolete”. Rather the maintainer has chosen a very unstable cadence of API breaks and we’re stuck with the fallout of that decision. Besides, nobody has made any decisions yet so no need to act as if I disagree with you about upgrading to 1.92. I’m still evaluating the situation.

[majvax]

Absolutely, English isn’t my first language, so I didn’t mean to imply you were against upgrading or that a decision was already made. I just wanted to highlight the challenges with the current version mismatch. You’re right, “obsolete” is probably too strong a word for something less than a year old, especially given how quickly ImGui evolves. But I do think ImGui usually handles backwards compatibility well by deprecating functions first, so updating once can often keep things stable for a while. That’s why I personally don’t see much value in supporting older versions, especially since the changelog is clear about breaking changes. But I understand you’re still evaluating, so I’m happy to wait and see what you decide.