Best practice for Emscripten / SDL

[avitase]

Hello,

I am successfully using glbinding in a combination of SDL and OpenGL 3.0 ES as an application running locally on my Desktop machine. However, I could (allegedly) easily port this thing to the web via Emscripten, too, since Emscripten does support SDL as an Emscripten Port. On their wiki I found the following warning, though:

Avoid using any of the *glGetProcAddress() API functions. Emscripten provides static linking to all of the GL API functions, even for all WebGL extensions. The *glGetProcAddress() API is only provided for compatibility to ease porting of existing code, but accessing WebGL via calling dynamically obtained function pointers is noticeably slower than direct function calls, due to extra function pointer security validation that dynamic dispatching has to do in asm.js/WebAssembly. Since Emscripten provides all of the GL entry points statically linked in, it is recommended to take advantage of this for best performance.

...which is exactly what I am (not) doing in my code:

::glbinding::initialize(
        reinterpret_cast<::glbinding::ProcAddress (*)(const char *)>(SDL_GL_GetProcAddress),
        /*resolve_functions=*/true);

According to ChatGPT it is totally fine to just change this to ::glbinding::initialize(nullptr, false) in case of an Emscripten build but somehow this seems to be fishy. What do you suggest? How should I deal with situations where symbols are linked statically?

Thanks for your help!

[scheibel]

glbinding was explicitly designed and is used for the optional parts of OpenGL, that are only accessible through use of dynamic function pointer resolution, e.g., glGetProcAddress, wglGetProcAddress, glxGetProcAddress, glfwGetProcAddress, among others. The main need comes from platforms, where the packaged OpenGL headers stopped with OpenGL 1.1.

When there is a full header of the API, this main reason does not exist.
However, I see that there are a number of additional features that someone would want from a foreign function interface, e.g., callbacks, logging, error detection, compile-time errors, and I'm also a fan of having glbinding with support for emscripten and similar technologies.

The tip of ChatGPT to provide a nullptr to the initialization routine does have intended behavior (at least on desktop platforms), which is as follows:

• Fallback to glbinding::getProcAddress for function pointer resolution, which is
• dlopen on libGL.so and per-function dlsym calls with a reinterpret cast
• ...however this translates to emscripten JavaScript...
• Source: https://github.com/cginternals/glbinding/blob/master/source/glbinding/source/getProcAddress.cpp#L44

My main approach would be an extension to the underlying code generator, where the function pointer resolution is not effectively used, but statically linked variants as proposed by emscripten.
However, I think this is considerable amount of development efforts.
We had previous requests and plans in this direction, but haven't come far:

• Add an example profile for "OpenGL / emscripten" khrbinding-generator#18
• Emscripten support #219
• Add parser for WebGL API khrbinding-generator#7