No way to use custom OpenGL ES loader

[ItIsApachee]

Branch of Dear ImGui:

Branch: master

Back-end/Renderer/Compiler/OS

Back-ends: imgui_impl_opengl3.cpp + imgui_impl_glfw.cpp

My Issue/Question:

In my project I'm using OpenGL ES 3 backend provided by ANGLE which implements it using other graphical backends. I would like to use ImGui in this project, but I don't see any other way to do this without changing imgui_impl_opengl3.cpp code other than:

1. #define IMGUI_IMPL_OPENGL_ES3
2. make it so that <GLES3/gl3.h> include path corresponds to the chosen OpenGL ES loader library (in my case, glad).

It would have been so much easier, and more customizable, if there was a way to provide the path to the loader using a define, for example:

--- a/backends/imgui_impl_opengl3.cpp
+++ b/backends/imgui_impl_opengl3.cpp
@@ -129,7 +129,11 @@
 #else
 #include <GLES3/gl3.h>          // Use GL ES 3
 #endif
-#elif !defined(IMGUI_IMPL_OPENGL_LOADER_CUSTOM)
+#elif defined(IMGUI_IMPL_OPENGL_LOADER_CUSTOM)
+#ifdef IMGUI_IMPL_OPENGL_LOADER_CUSTOM_PATH
+#include IMGUI_IMPL_OPENGL_LOADER_CUSTOM_PATH
+#endif
+#else
+// IMGL3W includes go here

UPD:
Also I didn't take in consideration, that since I'm using OpenGL ES 3 this wouldn't solve the issue completely, because the rest of the code should also be changed, as if IMGUI_IMPL_OPENGL_ES3 was defined, but with this define the solution provided by me isn't going to work. So to solve this issue there should be a way to provide a path to custom loader, but also define IMGUI_IMPL_OPENGL_ES3 to change the rest of the code appropriately.

[PathogenDavid]

See also #4810

It's somewhat intentional that you can't provide your own loader. In the past Dear ImGui required you to provide your own loader and it was an endless source of headaches and confusion, which is why we use our own.

Another alternative might be to define IMGUI_IMPL_OPENGL_LOADER_CUSTOM and include your loader in your imconfig.h. (This does mean your GL loader will be getting included everywhere you include imgui.h though.)

[ItIsApachee]

See also #4810

It's somewhat intentional that you can't provide your own loader. In the past Dear ImGui required you to provide your own loader and it was an endless source of headaches and confusion, which is why we use our own.

Wouldn't it be ok to provide additional ways to configure Dear ImGui? Now that there is a default loader, the existing codebases shouldn't break if a way to use your own loader is implemented. And also because there is a default loader, the only ones using custom loaders would be users, who, hopefully, know what they are doing.

Another alternative might be to define IMGUI_IMPL_OPENGL_LOADER_CUSTOM and include your loader in your imconfig.h. (This does mean your GL loader will be getting included everywhere you include imgui.h though.)

I considered that, but it seems like a pretty hacky way to solve the problem. There is also an option of creating my own imgui_impl_opengl3.cpp, and using it instead, but my version would differ only slightly from the original, and that is why I thought implementing a small change can provide more flexibility to imgui_impl_opengl3.cpp for those who need it.
I have no idea about what kind of problems people dealt with, when users were providing their own loaders, so my point of view is probably missing all the disadvantages of custom loaders.

[PathogenDavid]

Wouldn't it be ok to provide additional ways to configure Dear ImGui?

It sounds like a legitimate advanced scenario to me, but Omar has the final say.

I think the main concern is that if there's an obvious escape hatch for specifying your own loader people will use it for the wrong reasons.

A very common source of issues around here are university students using broken project templates provided by their professors with borderline insane configuration choices.

Another less common problem is third party package maintainers making weird configuration defaults on behalf of their consumers. I can definitely see an overzealous package maintainer thinking "Why should we distribute imgui_impl_opengl3_loader.h in our repackaged Dear ImGui when we can just have it reference the libgl3w package?" (If you think this sounds like a weirdly nitpicky thing to do: The Debian distribution of Dear ImGui references their stb package instead of using the imstb_ files we provide.)

I considered that, but it seems like a pretty hacky way to solve the problem.

It's sort of what it's intended for (it's specifically meant to support single file/unity builds), but yeah I get that.

[ocornut]

Wouldn't it be ok to provide additional ways to configure Dear ImGui?

It's not a matter of configuring Dear ImGui here.
You are free to use a different loader for your code.
But our code (specifically imgui_impl_opengl3.cpp) ideally should work in all scenarios, if it doesn't we have an issue to fix.

So the real question for me, why doesn't imgui_impl_opengl3.cpp work with ANGLE because afaik ANGLE provides ES compatible headers?

[ItIsApachee]

So the real question for me, why doesn't imgui_impl_opengl3.cpp work with ANGLE because afaik ANGLE provides ES compatible headers?

It does, but the problem is with imgui's shenanigans with cross-platform code that includes ES headers from some random places according to the platform-specific defines, but I can't recall my problem fully now that this much time has passed.

[MileyHollenberg]

Note I had the same issue today as well but it was relatively easy to fix. You just need to link the ImGui library to the libEGL.dll.lib of ANGLE and make sure IMGUI_IMPL_OPENGL_ES3 is defined in the OpenGL3 backend (there's a line for it already, just uncomment it). After this it started working right away for me :)