OpenGL backend now embeds its own GL loader (imgui_impl_opengl3_loader.h)

[ocornut]

TL;DR;

Our GL backend now embed its own minimal GL loader (embedded file; full source repo)
User/application don't need to configure anything related to GL loader.
User/application can use their own GL loader of choice regardless of what our backend does.
Thanks @rokups!

What is an OpenGL loader

Desktop OpenGL doesn't have standard portable header/libs files for all features GL offers.
Helper libraries are often used for this purpose. There are many of them: glew, glad, glbinding, glext to name a few (easy to recreate one). Those libraries tend to two things:

• They provide the defines/enums used by modern GL features and/or variety of extensions.
• They provide function pointers that one can call to access those GL features. During initialization the library loads e.g. the OpenGL DLL and assign those pointers to available functions.

WebGL and GL ES do not suffer from this as the headers and libraries are better standardized.

What our imgui_impl_opengl backend did (and the problems)

Until recently, the OpenGL3 backends and examples made a best effort to support variety of GL loaders. This turned to be a mistake which created confusion for users (many of them being newcomers to OpenGL, to Dear ImGui or to C++ programming in general), as this support relied on compile-time defines, plus an attempt at detecting available system includes (which I also now firmly regret).

To be able to provide examples that would compile out of the box we had to include a loader in the examples folder. We included gl3w, which was picked at the time because its output was small and neat, but as many existing GL users used another loader it was confusing for them.

What frequently happened is user's existing application used loader X and compiled our backend in a way that used loader Y which was either not initialized, either not linked. This made integrating Dear ImGui in an established OpenGL codebase more confusing.

Our setup, which required the user to provide and initialize (on their side) the GL loader that the backend used, unwillingly contributed to perpetuate a common misconception that "an application can't use multiple GL loaders". A loader is merely a bunch of defines and function pointers, of course we can!

Things got even more complicated as package managers like vcpkg are trying to provide a seamless experience where the user can grab e.g. "imgui" + "opengl3 backend" but that needed to drag loader libraries into the mix and they would need to be initialized by a call that vcpkg couldn't magically inject into user app. (See their issue microsoft/vcpkg#14753)

What are are now doing

(This is the work of @rokups)

We decided to simply embed and use own loader, solely for usage by imgui_impl_opengl3.cpp.
The new loader is backends/imgui_impl_opengl3_loader.h and automatically used by our backend.
If you update your backends by copying files, you'll have to grab this file too.

It means that it doesn't matter which GL loader your existing application is using. We don't care. We have our own. Both can cohabit.

Because we are committed to our bloat free approach, we had concerns with adding a "regular" loader inside backends/ as most available loaders are now a bit large. We forked gl3w into gl3w_stripped which greps for symbols used by imgui_impl_opengl3.cpp and only include the one we need. As a result, backends/imgui_impl_opengl3_loader.h is only about ~32 KB of source file and compiles to almost nothing.

That's all!

(
PS: on the unlikely case that your app ended up using our old copy of gl3w directly from our repository in examples/libs/gl3w: (1) You may access gl3w original repository https://github.com/skaslev/gl3w, (2) You may grab the files from dear imgui 1.83 repo, or (3) You may look at https://github.com/dearimgui/gl3w_stripped which is our fork of gl3w that handle filtering.
)

Links

Here's a partial list of issues related to compiling/linking/configuring GL loaders:

#4390 #4279 #4428 #3986 #3860 #3769 #3736 #3507 #3330 #3246 #2798 #3061 #2919 #2870 #2806 #2785 #2444 #2180 #2178 #2002 #2001 #1988 #1956 #1806 #1576 #880 #483

[metarutaiga]

This is my OpenGL ES 3.2 Loader. (Lazy import)
https://github.com/metarutaiga/TensorFlowLiteReduce/blob/master/third_party/GLES3/gl3_loader.c
https://github.com/metarutaiga/xxGraphic/blob/master/internal/xxGraphicInternalGL.cpp

1.It can prevent to run a null pointer calling.
2.Not to need include its header, like a library linking.
3.To add a function needs one line only.
4.It can reduce code size because it linked we need functions.

[nitrix]

This is great news and will help other programming language communities re-use the official C++ backend instead of each re-implementing their own due to problems with some loaders unable to cross the FFI boundary. Looks significantly simpler now, thank you.

[parbo]

After I updated to the version with this, the images I load with my (complete) gl3w loader end up black. If I replace #include "imgui_impl_opengl3_loader.h" with my own gl3w.h then it works. Am I not supposed to be able to create GL texture id's with one loader and use them with the new embedded one?

[ocornut]

Thanks for reporting @parbo. I can't understand how this would have an impact. The loader are essentially merely function pointers to GL functions and a bunch of defines. We also made sure that our forked-stripped-gl3w used non conflicting symbols so gl3w could still be used...
But it is arguably troubling if just replacing the header included from imgui_impl_opengl3.cpp works.
Could there be a difference in the #ifdef paths taken by the backend?

[parbo]

That was my theory too, but I didn't find anything obvious. I will try some more tomorrow..

[MachSilva]

When I updated it too and then executed the program, I got some memory access violations on Windows during the loader initialization. However, when I tried to compile the same project on Linux, I got "multiple definitions for gl3wProcs" during linking. It appears that the definitions for the union GL3WProcs are different in the files gl3w.c and imgui_impl_opengl3.h. Could it be the reason for your black images?

[ocornut]

OK it looks like we broke something (@rokups?) the symbols in that file are called gl3wProcs and not static, it might conflict with another copy of gl3w.

[ocornut]

@parbo @MachSilva in imgui_impl_opengl3_loader.h

Can you try renaming gl3wProcs to imgl3wProcs (using CASE SENSITIVE, FULL WORD search & replace to not mess with the union name).

It should be those lines:

GL3W_API extern union GL3WProcs imgl3wProcs;
...
#define glActiveTexture                  imgl3wProcs.gl.ActiveTexture
#define glAttachShader                   imgl3wProcs.gl.AttachShader
+ 50 others
...
GL3W_API union GL3WProcs imgl3wProcs;
...
 imgl3wProcs.ptr[i] = proc(proc_names[i]);

[MachSilva]

Yes. It solved my problem on both platforms. Thank you.

[parbo]

It does indeed fix my problems too!

[ocornut]

Merged 4c22b3e to fix this.

[Slluxx]

the loader is including "<dlfcn.h>", which is not present on my embedded system. I am not sure how to resolve this issue. Am i stuck on an earlier version?

[ocornut]

@Slluxx which loader did you use that worked in the earlier version? Whats your embedded system and how did the previous loader access the functions?

[Slluxx]

i was using imgui v1.77, which did not have a loader file. If it did but hidden, then im unsure about the details.
Im using the nintendo switch, glfw and opengl3.

[ocornut]

It always used a loader. Add a printf in the init function to display the gl_loader variable and find which one you used. I would like to get this fixed but we can’t do it without the help of affected users.

[feipiefei]

could you please teach me how to solve this problem
""" fatal error C1189: #error: "Cannot detect OpenGL loader!" """,

[ocornut]

@feipiefei This is not a problem anymore with latest version.

[Slluxx]

It always used a loader. Add a printf in the init function to display the gl_loader variable and find which one you used. I would like to get this fixed but we can’t do it without the help of affected users.

sorry for the super late reply, i havent tried to update since then.
gl_loader is "glad". now i am struggeling to figure out how to get it back working

[ocornut]

Well we should look how GLAD worked on your system and mimick that.
What's your Nintendo Switch SDK name/version?
Maybe get back to a old setup with GLAD and see what code GLAD calls.

If I skim at GLAD sources (https://glad.dav1d.de/)
It seems to always use <dlfcn.h> on non-Windows systems, so I think the assumption that dlfcn.h is not available on your compiler setup may be wrong...

[Slluxx]

I am just using a plain old hacked switch together with a toolchain from devkitpro.
There are a few examples on how to work with GLAD on the system, one being this.

In my 1.77 code, i use imgui_impl_opengl3 and imgui_impl_glfw and none of them seem to include <dlfcn.h>.
Maybe i am just doing something super wrong? all that glad, glfw, opengl, gles, ... stuff is very confusing.

I wish markdown had spoilers. Anyway, this code works on my console.

#include "imgui/imgui.h"
#include "imgui/imgui_internal.h"
#include "imgui/imgui_impl_glfw_switch.h" // dont mind "custom" the filename. there is nothing custom in the file.
#include "imgui/imgui_impl_opengl3.h"

#define STB_IMAGE_IMPLEMENTATION
#include "stb_image.h"

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <switch.h>
#include <chrono>
#include <set>
#include <thread>
#include <string>
#include <vector>
#include <iterator>
#include <map>
#include <dirent.h>

#define GLFW_INCLUDE_NONE
#include <GLFW/glfw3.h>
#include <glad/glad.h>
#define GLM_FORCE_PURE
#define GLM_ENABLE_EXPERIMENTAL
#include <glm/gtc/matrix_transform.hpp>
#include <glm/gtc/type_ptr.hpp>
#include <glm/gtx/rotate_vector.hpp>
#include <glm/mat4x4.hpp>
#include <glm/vec3.hpp>
#include <glm/vec4.hpp>

#include "helper.hpp"
#include "IconsFontAwesome4.h"

      // Init glfw
    glfwSetErrorCallback(errorCallback);
    glfwInitHint(GLFW_JOYSTICK_HAT_BUTTONS, GLFW_FALSE);
    if (!glfwInit())
        return false;

    const char *glsl_version = "#version 430 core";
    glfwWindowHint(GLFW_CONTEXT_VERSION_MAJOR, 4);
    glfwWindowHint(GLFW_CONTEXT_VERSION_MINOR, 3);
    glfwWindowHint(GLFW_OPENGL_PROFILE, GLFW_OPENGL_CORE_PROFILE);

    GLFWwindow *window = glfwCreateWindow(WINDOW_WIDTH, WINDOW_HEIGHT, "test", nullptr, nullptr);
    if (!window)
        glfwTerminate();

    glfwSetInputMode(window, GLFW_STICKY_KEYS, GLFW_TRUE);
    glfwMakeContextCurrent(window);
    gladLoadGLLoader((GLADloadproc)glfwGetProcAddress);
    glfwSwapInterval(1);


    // imgui init
    // ...
    ImGui_ImplGlfw_InitForOpenGL(window, true);
    ImGui_ImplOpenGL3_Init(glsl_version);

    // Main loop
    while (!glfwWindowShouldClose(window))
    {
        glfwPollEvents();
        ImGui_ImplOpenGL3_NewFrame();
        ImGui_ImplGlfw_NewFrame();
        ImGui::NewFrame();

        // main window code

        // Rendering
        ImGui::Render();
        int display_w, display_h;
        glfwGetFramebufferSize(window, &display_w, &display_h);
        glViewport(0, 0, display_w, display_h);
        glClearColor(0.45f,  0.55f,  0.60f, 1.00f);
        glClear(GL_COLOR_BUFFER_BIT);
        ImGui_ImplOpenGL3_RenderDrawData(ImGui::GetDrawData());

        glfwSwapBuffers(window);
    }

    // Cleanup
    ImGui_ImplOpenGL3_Shutdown();
    ImGui_ImplGlfw_Shutdown();
    ImGui::DestroyContext();
    glfwDestroyWindow(window);
    glfwTerminate();
    return 0;

[ocornut]

Where's the code for GLAD.c ?
Glad.c here seems to always include dlfnc.h

We should probably include a way to optional pass in a function loader to the OpenGL backend, may help some users, but right now I don't see how things would compile.

[Slluxx]

@ocornut here it is

[ocornut]

@ocornut here it is

@Slluxx Somebody would need to study that version of Glad and see how the logic can be ported to our GL3W, find how to make it compile and if we can make it possible for your code to initialize it with a custom GL3WGetProcAddressProc function.
This should be done by someone using your devkit.

[ocornut]

Closing this as idle (and the big issue/news is done).

@Slluxx I am open to add support for a custom loader function, but someone using that homebrew Switch SDK would need to investigate this and submit the PR.