use GLAD to link OpenGL

[mbaetgen-wup]

Changes

• Add GLAD as vendor lib with static linking
• Replace projectM system GL dependencies with GLAD
• Remove GLEW
• Remove CMake module for GLES and GLES dependency (GL dependency is still needed for linking on Windows)
• Add C api function for creating projectM with an app supplied resolver for GL function pointers
• Add resolver to handle GL function pointer discovery
• Verify GL requirements, context current, assert api / glsl / version
• Log GL details, resolver details, errors
• Adjust sdl-test-ui to discover GL functions from SDL
• GLAD 2.0.8
  • OpenGL 3.3
  • GLES 3.2
  • EGL 1.4
  • WGL 1.0
  • no extensions
  • options: alias =true, loader=true

Test status - OS/GL API

• GLX: ok
• GLES (Linux, Windows: WGL via GLAD, EGL via ANGLE): ok
• WGL: ok
• EGL+GL Core Profile (Linux/Wayland): ok
• Android: ok
• Emscripten: ok
• MacOS: ok

Test status - framework integrations

• ANGLE (Windows): ok
• Gstreamer (GLX, EGL, GLES): ok
• SDL2 (GLX, EGL, WGL, GLES): ok
• SDL3: todo
• Qt: todo

closes #681

[mbaetgen-wup]

@kblaschke I have been testing the glad integration. It's starting to shape up, I was able to run projectM with egl + gl core profile 3.3. Now I am looking at wrapping up the lifecycle management for the resolver. There are 2 options: Using glad with MX (multi-context) or without. Technically, the C api with projectm_create_with_opengl_load_proc(...) allows to pass a different resolver function for each projectM instance. That would require MX, the resolver to be non-static, and each gl call needs the glad context. That would mean storing the glad context somewhere, e.g. on the ProjectM class and passing it around in some way, most likely as a call argument. So question is, either keep it simple, only one resolver is allowed per process (shared by all projectM instances) or allow multi-contexts, deal with the complexity of passing the glad context around (may enable runtime detection of GL/GLES some day though).

[kblaschke]

Just keep it simple for now.

I don't think a single application would use different GL implementations within the same process. Multiple GL contexts, sure, but these would all use the same GL functions and libraries. The only use for this I can imagine would be some development test application which runs projectM on multiple backends in parallel for direct comparison, but this can easily be done with several processes as well. For end users, this is an edge case nobody really needs IMO, so a single set of functions is good for now.

Besides that, changing to multi-context would only require internal refactoring and no API changes as the resolver callback is already per-instance. I'd postpone this and only implement if there's a real-world demand for it.

[rootnotez]

Compiled and ran, with this fix. _SDL2_TARGET_TYPE appears unused, so AND test can never pass. Also, even if the conditional wasn't broken, it would only apply for Static builds.

diff --git a/cmake/SDL2Target.cmake b/cmake/SDL2Target.cmake
index a949078f8..0f0de2a6e 100644
--- a/cmake/SDL2Target.cmake
+++ b/cmake/SDL2Target.cmake
@@ -55,7 +55,7 @@ endif()

 # Temporary fix to deal with wrong include dir set by SDL2's CMake configuration.
 get_target_property(_SDL2_INCLUDE_DIR SDL2::SDL2 INTERFACE_INCLUDE_DIRECTORIES)
-if(_SDL2_INCLUDE_DIR MATCHES "(.+)/SDL2\$" AND _SDL2_TARGET_TYPE STREQUAL STATIC_LIBRARY)
+if(_SDL2_INCLUDE_DIR MATCHES "(.+)/SDL2\$")
     # Check if SDL2::SDL2 is aliased to SDL2::SDL2-static (will be the case for static-only builds)
     get_target_property(_SDL2_ALIASED_TARGET SDL2::SDL2 ALIASED_TARGET)
     if(_SDL2_ALIASED_TARGET)

Built with directions here: https://github.com/projectM-visualizer/projectm/blob/master/BUILDING-cmake.md?plain=1#L21-L26

cmake .. -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX=/usr/local -DENABLE_SDL_UI=ON

cmake --build . --target install --config Release

M1 Mac Air
Sequoia 15.7.2

[kblaschke]

Compiled and ran, with this fix. _SDL2_TARGET_TYPE appears unused, so AND test can never pass. Also, even if the conditional wasn't broken, it would only apply for Static builds.

Yeah, it's a remnant of older SDL2 releases. They've been changing the CMake config scripts multiple times over different releases, so this check might require some additional branching for older SDL releases. We can also try and find out when this behavior actually changed (probably at some point after the 2.0.16 release), and make this version the minimum build requirement. At runtime, it's not an issue as SDL2 is fully backwards compatible at the ABI/API level.

[mbaetgen-wup]

The last issue that I am trying to get right is with Emscripten. Currently projectm_create() does not work, projectm_create_with_opengl_load_proc() has to be used with SDL_GL_GetProcAddress() within the Emscipten app, that works fine. The GLAD resolver does not really make sense for Emscripten, since it's not a "real" OpenGL environment. Bypassing GLAD entirely for Emscripten would be possible, but introduces a lot of ugly #ifdef, all the way to SOIL2.

[mbaetgen-wup]

Turned out there is a simple way to support Emscripten/WebGL in the resolver.

[mbaetgen-wup]

re-tested GLX, GLES, EGL, WGL, Emscripten and Android

[mbaetgen-wup]

I think the resolver should be reasonably robust now.
re-tested:

• Linux/Wayland: EGL+GL, EGL+GLES
• Linux/X11: GLX+GL, GLX+GLES
• Windows: WGL+GL, WGL+GLES (via GLAD), ANGLE/EGL+GLES
• Android
• Emscripten

[rootnotez]

Can you elaborate on how you are running on these test platforms? Is this all in the cloud? Or since this is LibProjectM; is this just testing that it compiles?

May want to add some more linux targets, like different versions of deb/Ubuntu; as well as Redhat and an Arch/Bazzite exotic distro.

I also think it needs testing against different GPUs, because they package their own GL libs. - Noveau, Nividia, AMD, Intel, Raspberri Pi / ARM. Great work 👍

[mbaetgen-wup]

Nothing fancy. It's a painful manual process. 2 computers, one with Mint (X11/Nvidia) and Ubuntu (Wayland/AMD) and dual-boot Windows. I am starting up the sdl-test-ui everywhere, build with and without gles, and let it render a preset. Also running gstreamer for testing. I got the Android example updated, using that to test Android, build the app, run on an ARM emulator. For Emscripten I got the example running. So I actually start them up and look if it renders.

[mbaetgen-wup]

ANGLE can be pulled in via vcpkg and CMake, so it requires a few changes to the build files, but it's to quick to.

[kblaschke]

Building on Linux with GLX/X11 still gives me linker errors:

/usr/lib/gcc/x86_64-pc-linux-gnu/14/../../../../x86_64-pc-linux-gnu/bin/ld: src/libprojectM/libprojectM-4d.so.4.1.0: undefined reference to `XScreenNumberOfScreen'
/usr/lib/gcc/x86_64-pc-linux-gnu/14/../../../../x86_64-pc-linux-gnu/bin/ld: src/libprojectM/libprojectM-4d.so.4.1.0: undefined reference to `XOpenDisplay'
/usr/lib/gcc/x86_64-pc-linux-gnu/14/../../../../x86_64-pc-linux-gnu/bin/ld: src/libprojectM/libprojectM-4d.so.4.1.0: undefined reference to `XDefaultScreenOfDisplay'

There are two possible solutions I could imagine:

1. Define GLAD_GLX_NO_X11 and disable GLX support, which is fine as we don't use any GLX extensions
2. Resolve these three functions dynamically, same as the GL functions, and bail out if they aren't available.

I'd personally go with 1, see my suggestion below for a quick fix.

[kblaschke]

Is this really required on Windows? glad should load opengl32.dll from the OS, which is exactly what we'd link here.

[mbaetgen-wup]

yes, for some reason, it appears to be a hard requirement to link opengl32.dll on Windows for desktop GL.

[kblaschke]

I'd suggest to define a typedef for the load_proc callback, as it's easier to read/find, we can add specific Doxygen documentation for the callback there and it can be used as a type in proxy functions if needed.

See callbacks.h for examples.

[kblaschke]

Tested everything at least on Linux, works just fine!

One little edit I've overlooked so far: now that GLEW is gone, the Windows-only dependency should be removed from the vcpkg.json as well (just delete the lines marked in the link).

After that, I guess we are ready merge it. Any small issues popping up, if there are any, can be fixed later.

[mbaetgen-wup]

Testing done. Retested Linux (GLX, EGL, Angle+Vulkan, GLES) on X11 and Wayland in some combinations, Windows (WGL, GLES, Angle), Android, Emscripten, Gstreamer, SDL2.

One thing to note is that some environments provide GLES 3.1 only (the Android emulator I used, Angle on Windows).
Gates are set to GL 3.3 / GLSL 3.30 or GLES 3.2 / GLSL ES 3.20.