Use GLAD for all OpenGL demos

[ccawley2011]

No description provided.

[oflebbe]

I love that idea. One external dependency less using GLAD as header library.

[aichingm]

What is the benefit of this, what issue is this solving?

I don't like the idea of adding a bunch of auto generated code to a git repository at all (could be handled by adding a make target which pulls the header but then building the demos depends on a third party web tool).

I personally like that the demos are very minimal examples without any bloat. That makes them adaptable to any use-case/scenario.

[sleeptightAnsiC]

I love that idea. One external dependency less using GLAD as header library.

This simply swaps one dependency for another, with the only difference that we now have 18k more LoC in the repo. I would even consider it to be worse, because GLAD is meant to be highly configurable, and this would enforce a specific config of it.

What is the benefit of this, what issue is this solving?

I guess, there is one less package that you have to fetch, but for me it does not make much sense, because you already have to fetch glfw/sdl/sfml or whatever else the demo needs. So in practice this does not help much.

I don't like the idea of adding a bunch of auto generated code to a git repository at all

I must agree.

Also, this PR forces GLAD into demos that do not need it, like the SDL ones. Why would we need it there?

Also also, the demo/*/main.c files are for developers to take and change on their own. If someone want to use different GL loader, you can already do this.

@ccawley2011 If you're having any problems with demos that GLAD solves for you, please report those as Issues first. Suggesting to casually Use GLAD for all OpenGL demos without any context given can't be taken serious.

[ccawley2011]

The biggest advantage of GLAD is that it supports OpenGL ES while GLEW does not. It also allows switching between OpenGL implementations by using the SDL_GL_GetProcAddress/glfwGetProcAddress/sf::Context::getFunction/glXGetProcAddressARB functions, which would allow for some of the demos to be combined (particularly the GL3 and ES2 demos) without much difficulty in follow-up PRs.

It also makes it simpler to build the SFML demos, which already require GLAD regardless of this PR.

[sleeptightAnsiC]

Okay, I'm beginning to understand

The biggest advantage of GLAD is that it supports OpenGL ES while GLEW does not.

Yes, that is a valid point, however, do we need a static copy to achieve this? A lot of distros can provide GLAD and it's trivial to get one via https://gen.glad.sh/ Is there a specific reason why should we vendor this code inside of git repo? Is our CI runner unable to fetch it or something like that? Genuinely asking here.

It also allows switching between OpenGL implementations by using the SDL_GL_GetProcAddress/glfwGetProcAddress/sf::Context::getFunction/glXGetProcAddressARB functions [...]

At the point where someone needs this functionality, they have to implement it inside of their own code and need to know what to do. So I would expect that the person doing this will know how to get GLAD themself.

[...] which would allow for some of the demos to be combined (particularly the GL3 and ES2 demos) without much difficulty in follow-up PRs.

This is actually something that I've been thinking about a lot recently. I've started some conversation about this exact topic on Nuklear's Discord server today. @ccawley2011 I would like to invite you to join us there since you have some good points 😉 https://discord.com/invite/M3QKFsUdaV

My initial idea to fix this problem was to "simply load all the function pointers on our own" [ref1] Because most of those demos only need very few distinct GL calls, it shouldn't be too hard to implement a very simple loader.

I was also suggesting to "merge all OpenGL implementations into the one where you would be able to pick which GL version and/or profile you want at runtime" [ref2] That one would be harder but still possible, I think. It would solve all gl1/gl2/gl3/gl4/gles1/gles2/gles3 permutations. Many of those share the very same code.

Genuinely want to know what do you think about this?

[ccawley2011]

Yes, that is a valid point, however, do we need a static copy to achieve this? A lot of distros can provide GLAD and it's trivial to get one via https://gen.glad.sh/ Is there a specific reason why should we vendor this code inside of git repo? Is our CI runner unable to fetch it or something like that? Genuinely asking here.

Repology has a list of distros that contain GLAD, and it's not present in Debian, Fedora, Homebrew or MSYS2, so relying on a system-wide version would exclude most users. It might be possible to get GitHub Actions to generate it automatically, but that would require a lot more work.

My initial idea to fix this problem was to "simply load all the function pointers on our own" [ref1] Because most of those demos only need very few distinct GL calls, it shouldn't be too hard to implement a very simple loader.

IIRC that was my first thought, and the x11_opengl3 demo supports doing that already, but I think the OpenGL 4 demo complicates things by using a bunch of other stuff. It's been a while since I looked at this though.

I was also suggesting to "merge all OpenGL implementations into the one where you would be able to pick which GL version and/or profile you want at runtime" [ref2] That one would be harder but still possible, I think. It would solve all gl1/gl2/gl3/gl4/gles1/gles2/gles3 permutations. Many of those share the very same code.

It might be better to keep the fixed function (GL1, GLES1) and shader (GL2, GLES2, later versions) variants somewhat separate, but it should be doable.

[sleeptightAnsiC]

Alright, thanks!

I hope there will be some movement on this topic soon. I'll try to remember to ping you in case I have some news on this.

Repology has a list of distros that contain GLAD, and it's not present in Debian, Fedora, Homebrew or MSYS2

Debian 13 doesn't ship the generated library itself, but it does ship the generator under python3-glad. Same with MSYS2, so I would expect it's a similar case for other distros. Though I get your point.

It might be better to keep the fixed function (GL1, GLES1) and shader (GL2, GLES2, later versions) variants somewhat separate, but it should be doable.

Yes, this definitely needs to be considered. I'm also afraid that big monolithic GL backend may scare some people.