add emscripten support to the loader about glad-web HOT 7 CLOSED

Just for reference for anyone who may be reading this: In emscripten there is no need for any OpenGL loader, simply #include <GL/gl.h> and it will automatically use emscripten's built-in OpenGL stuff.

If you have a project that can be in both native mode and emscripten, then you can create a simple OpenGL wrapper header:

opengl.h

#ifdef __EMSCRIPTEN__
// For emscripten, instead of using glad we use its built-in support for OpenGL:
#include <GL/gl.h>
#else
#include "glad.h"
#endif

And then just include this "opengl.h" header everywhere you need it. Also, in your main function, you can check the same __EMSCRIPTEN__ ifdef to determine if glad should be initialized

from glad-web.

Good idea.

Jfyi you can already use glad with emscripten: gladLoadGLLoader((GLADloadproc) emscripten_GetProcAddress).

I'll track the issue in the main repository.

from glad-web.

Has been added to the glad2 branch, playing around with it, it seems like it would only be useful if you're using neither glfw nor SDL.

from glad-web.

Please do not use emscripten_GetProcAddress. It is slow and should not be used.

Here is the quote directly from the emscripten wiki:

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.

https://kripken.github.io/emscripten-site/docs/optimizing/Optimizing-WebGL.html#optimizing-load-times-and-other-best-practices

from glad-web.

@bitc Thanks, I'll keep that in mind, for now the function pointer loading thing just did fit more into the current way of how things worked within glad. For static linking I'll probably have to add an extra option if you want otherwise the headers will get even more bloated.

from glad-web.

There are other platforms where it isn't necessary to look up the functions dynamically, yet I gladly use glad to get consistent headers everywhere, and to keep such ifdefs out of my code. It would be great if glad supports emscripten through the same API as all other platforms.

from glad-web.

@zajo The glad2 branch has the non-optimal (as described above) loading integrated: gles2_glfw_emscripten.

from glad-web.