Non-GL-API packages may not work out of the box

[errcw]

Investigate whether all APIs at a minimum compile and can be initialized.

[capnm]

In fact, I believe ./glow generate -api=glx -version=1.4 generates a far from usable code ...

[capnm]

"Availability is determined at Init time based on the ability to load the relevant functions (not via glGetString(GL_EXTENSIONS))."

I wonder why. That seems to be to me completely pointless. The 2.1 driver/lib happily returns a pointer to a 4.4 function. The unimplemented function just does nothing. Maybe it's again a Linux or driver thing?

[errcw]

The 2.1 driver/lib happily returns a pointer to a 4.4 function. The unimplemented function just does nothing. Maybe it's again a Linux or driver thing?

Interesting. On Windows and OS X, at least the machines I used to test, unavailable extension functions fail to load.

Ultimately I'm not sure it's Glow's responsibility to manage extension availability. A library or the application should use the Glow OpenGL API primitives to make the determination. I only wanted Glow to provide an API for exposing which groups of optional functions loaded successfully.

[capnm]

I can now run the cube example without glfw (only with the glx lib) which is great, but I'm certainly missing the big picture here.

Some extensions appear to have same name in gl and glx/w but different functionality e.g.: https://www.opengl.org/registry/specs/NV/copy_image.txt

CGO then stops with an error about symbol collision. The same happens if you try to use more than one OpenGL API in same Go program.

How did you intended to use the bindings? Any real application need to support more than one OpenGL API. E.g. for a recent Linux distribution and hardware I suspect for my app: about 50% 2.1/GLSL1.2 (Intel/vmware), 30% 3.0 (AMD open source) and the rest 4.4 AMD or nvidia proprietary diver users.

[errcw]

I can now run the cube example without glfw (only with the glx lib) which is great

That is very, very cool! Please consider pushing your changes upstream when you're ready and/or contributing a new example.

CGO then stops with an error about symbol collision. The same happens if you try to use more than one OpenGL API in same Go program.

This is a use case I had not explored/considered. Well, I naively expected it to "just work" but of course anything untested is broken. It should be possible to annotate the C function names with package-specific prefixes or suffixes to resolve the name collision issue. I've filed Issue #12 to resolve this particular bug.

Thanks for bearing with the growing pains of a very young package!

[capnm]

That is very, very cool! Please consider pushing your changes upstream when you're ready and/or contributing a new example.

You won't like it. I think, we have a different goals. I will build a higher level package, hence I intend to use the output of glow as template for an iterative bottom up development. The glow generated code is great for this, eg. it doesn't implement someones other stupid ideas ;-) like the other packages out there. I can go step by step through our java code base and decide what should be written in Go and what is much easier to write in C.

Anyway, you can take a look if you will. Here is my experimental GLX code for your cube example. I was surprised that it runs (glow 3.3 core api + a minor shader syntax change) on hardware between OpenGL 2.1 and OpenGL 4.4.

• https://github.com/capnm/go3d_wip1

[errcw]

Thanks for sharing.

I was suggesting that I imagine you had to make non-trivial changes to the generated glx code in order for it to work. If those changes can be easily generalized we could fold them into the generator such that the glow-generated output for glx packages works out of the box. At that point we could offer prebuilt glx packages on which your project could rely, and we could link to your project as an example of glx usage.

[capnm]

I came to the conclusion, that generating an useful glx code isn't without a major effort doable or even worth doing it. It is subtle wired to the X11. The way the cgo works makes it outside the generated file very difficult to deal with the C structures. Memory-leaks at every corner. I think 1.4 is the last version and in a year or two it's dead anyway.

My next target will be the EGL 1.5. Here I guess, would a better code make more sense. At a first glance running go fmt shows, the code isn't a valid Go code. It would be great, when yo have time, if you could take a look at that. Thanks!

[capnm]

RFC: write the C part to an #included external file. It's easier to read and probably gives more luck to get useful CGo error messages.

[bryanturley]

This code is dead don't use it for anything but an example on how I solved this problem. https://github.com/bryanturley/old_gl/tree/master/glx14 (all cgo based, no asm)

funcs.go and enums.go are generated from the glx.xml file. I manually wrote x11.go. I had gout running on this back when I kept pieces of it scattered around so ignore the gout files. Every time I ran my old generator it would overwrite funcs.go and enums.go and leave the rest of the files intact. This gives you the extensions for glx and the missing pieces of x11 that you need to create a window and read events.

Not sure if it even compiles anymore and the event code is a bit dated (but still valid) ;)