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.

[Flat]

I'd like to also suggest looking into https://github.com/anholt/libepoxy, it is very simple to implement over glad, and doesn't require much more than including the header/linking and provides support for OpenGL/GLES/EGL.

[RobLoach]

GLAD is widely used and supported. I'd be fine with having this in. Mind fixing the conflicts?

Regarding libepoxy, it looks promising, but doesn't look quite as widely used. Possibly consider it for a follow up if it proves beneficial.

[sleeptightAnsiC]

I've been looking through bunch of Issues/PRs, and I think this is a good change after all, even with generated code checked into the repo.

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

I've also seen people trying to build some demos on Emscripten and Android where GLEW obviously doesn't really work, so the argument for GLAD makes perfect sense.

I want to ask about few details:

• Why there is so many (117) extensions enabled? Is any demo depending on these (e.g. for compatibility between various GL / GLES versions)? If not, can we just disable (at least some of) these?
• If my previous point is valid, can we also disable ALIAS option? I always found it to be quite hacky, and I'm a bit concerned it could cause some confusion.
• Can we enable ON_DEMAND option? I remember seeing some overhead in the past where loading all function pointers ahead of time was noticeable, and I do care about fast startup time of the demos, because I often use VMs to test my patches.
• Should we have some script that would clone specific tag/commit from GLAD repo and regenerate this file with pre-applied options? It would NOT be part of CI, but rather something that Maintainer/Contributor can quickly run locally. I could write this one.

I can overtake this PR and resubmit it with my points applied, and with all conflicts solved. Just let me know, if you agree or not.

^ @ccawley2011 @RobLoach (sorry for tagging, I hope you don't mind)

I already wanted to deal with #813, and to add some CIs for #895, and ccawley's work at #873 is currently blocked by this change, so I thought I would step in and move things forward.

We can also change some of GLAD options later. Not a big problem really.