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

ocornut commented

2021-08-19 14:24:44 +00:00

(Migrated from github.com)

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 https://github.com/microsoft/vcpkg/issues/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

### TL;DR; Our GL backend now embed its own minimal GL loader ([embedded file](https://github.com/ocornut/imgui/blob/master/backends/imgui_impl_opengl3_loader.h); [full source repo](https://github.com/dearimgui/gl3w_stripped)) 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](https://github.com/skaslev/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](https://github.com/microsoft/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 https://github.com/microsoft/vcpkg/issues/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](https://github.com/ocornut/imgui/blob/master/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](https://github.com/dearimgui/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](https://github.com/ocornut/imgui/blob/master/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](https://github.com/ocornut/imgui/tree/v1.83/examples/libs/gl3w/GL), 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

👍 17 🎉 5

metarutaiga commented

2021-08-20 00:29:18 +00:00

(Migrated from github.com)

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.

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 commented

2021-08-22 06:27:38 +00:00

(Migrated from github.com)

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 commented

2021-08-23 17:43:53 +00:00

(Migrated from github.com)

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?

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 commented

2021-08-23 18:12:27 +00:00

(Migrated from github.com)

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?

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 commented

2021-08-23 18:20:12 +00:00

(Migrated from github.com)

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

MachSilva commented

2021-08-23 20:25:07 +00:00

(Migrated from github.com)

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 commented

2021-08-23 20:32:14 +00:00

(Migrated from github.com)

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.

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.

👀 1

ocornut commented

2021-08-23 20:40:19 +00:00

(Migrated from github.com)

@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]);

@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 commented

2021-08-23 20:50:32 +00:00

(Migrated from github.com)

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

parbo commented

2021-08-24 06:14:03 +00:00

(Migrated from github.com)

It does indeed fix my problems too!

ocornut commented

2021-08-24 12:33:32 +00:00

(Migrated from github.com)

Merged 4c22b3e5 to fix this.

Merged 4c22b3e5 to fix this.

Slluxx commented

2021-09-03 21:27:33 +00:00

(Migrated from github.com)

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 commented

2021-09-03 22:18:22 +00:00

(Migrated from github.com)

@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 commented

2021-09-03 22:36:30 +00:00

(Migrated from github.com)

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.

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 commented

2021-09-03 22:43:39 +00:00

(Migrated from github.com)

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.

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 commented

2021-09-21 15:12:17 +00:00

(Migrated from github.com)

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

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

ocornut commented

2021-09-21 15:15:00 +00:00

(Migrated from github.com)

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

Slluxx commented

2021-12-20 00:20:19 +00:00

(Migrated from github.com)

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

> 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 commented

2021-12-20 12:24:05 +00:00

(Migrated from github.com)

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...

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 commented

2021-12-20 18:26:04 +00:00

(Migrated from github.com)

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;

I am just using a plain old hacked switch together with a toolchain from [devkitpro](https://switchbrew.org/w/index.php?title=Setting_up_Development_Environment). There are a few examples on how to work with GLAD on the system, one being [this](https://github.com/switchbrew/switch-examples/blob/e423a0ab0e8aadb16bede2289f412b8e1036243f/graphics/opengl/gpu_console/source/gpu_console.cpp). 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. ```c++ #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" ``` ```c++ // 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; ```

👍 1

ocornut commented

2021-12-20 18:34:25 +00:00

(Migrated from github.com)

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.

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 commented

2021-12-20 20:37:10 +00:00

(Migrated from github.com)

@ocornut here it is

@ocornut [here it is](https://github.com/devkitPro/switch-glad/blob/master/source/glad.c)

👀 1

ocornut commented

2022-07-01 12:36:37 +00:00

(Migrated from github.com)

@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 [here it is](https://github.com/devkitPro/switch-glad/blob/master/source/glad.c) @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 commented

2022-09-14 13:05:01 +00:00

(Migrated from github.com)

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.

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.

Rows
Columns

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

TL;DR;

What is an OpenGL loader

What our imgui_impl_opengl backend did (and the problems)

What are are now doing

Links