Choices in Go OpenGL bindings

[Dmitri Shuralyov]

It seems by now we have quite a few choices for OpenGL bindings:

github.com/go-gl/gl

github.com/chsc/gogl

github.com/chsc/gogl2

github.com/errcw/glow

Those are ones I'm aware of.

Given that all these packages are open source and have similar intents (with some variation in how the goal is achieved), I want to ask in the most respectful way possible, are all of them necessary, or can we do some consolidation?

I've personally used github.com/go-gl/gl in the past, and it worked well, but I moved to github.com/chsc/gogl eventually because it had a notable advantage:

- native Go package without external dependencies (unlike go-gl/gl which requires glew to be installed)

As far as I know, gogl2 was supposed to be an improvement over gogl by using a more advanced OpenGL XML parser, but it may or may not be production ready at this time.

On the other hand, glow is a fork of gogl2 which seems to be actively developed and likely "production ready". I haven't had a chance to try it yet, but I may do that and see how it compares to gogl (for my basic needs, anyway).

---

I think if the developers/maintainers can agree to work together, the best way to move forward would be to share push rights to the repos, but ask that feature development takes place on branches, and request to have at least 1 other person give a LGTM before merging PRs.

That way, as long as there are just 2 active people, development can be done quickly without PRs being unmerged for weeks, and by having 2 people say LGTM it helps make sure we're on track to have high quality Go packages.

Please share your thoughts if you think the above is a good idea.

[Eric Woroshow]

As the author of glow here's my take on the Go OpenGL binding landscape. The gogl, gogl2, and glow packages expose low-level windows onto the OpenGL API (i.e., they provide C-equivalent functions and constants). The go-gl/gl package provides a Go wrapper around the OpenGL API. The packages accomplish different goals so I believe there is room for both sets; indeed go-gl/gl could reasonably built on top of glow.

With glow I intended to built a replacement for GoGL and GoGL2. The original GoGL is consumes the obsolete OpenGL spec files and as a result is missing features (e.g., OpenGL 4.4 support) and requires refactoring for continued maintenance. GoGL2 was intended to be a replacement for GoGL that consumes the newer XML API registry information. My initial work on Glow was intended for GoGL2 but the author sanctioned a fork when he decided to stop working on GoGL2.

Ultimately having a single, canonical set of OpenGL bindings used by the Go community would be great, and I'm happy to discuss where glow would fit in such a world.

[Bryan Turley]

I am on my third gl binding generator.
While writing the generators I have also been writing something along the lines of sdl2/glfw in as much go as possible.
I didn't like the idea of using a c library that could be written in go.

While working on these two projects I got very frustrated with cgo so I wrote something with a bit more narrow focus that I could use in it's place.
The primary goal was using as much go as possible.
All of these are go gettable and still evolving.

* https://github.com/bryanturley/glgen3
spits out .sad files that are actually .go files.
example: https://github.com/bryanturley/gl/blob/master/gl4_4_amd64.sad
* https://github.com/bryanturley/sad/tree/master/sad
reads the .sad files with the stdlib's go/parse, go/ast stuff and
turns them into large .s file with a support .go and .c (for 6c)
sad is a tiny sliver of a bad compiler ;)
I hand wrote some sad files
example: https://github.com/bryanturley/x11/blob/master/x11_linux_amd64.sad
then I added objc class support for cocoa,
which turned out to work REALLY well
https://github.com/bryanturley/cocoa/blob/master/cocoa.sad
* https://github.com/bryanturley/gl
Read the "Automagic" section of the readme.
https://github.com/bryanturley/gl/blob/master/README.md

* https://github.com/bryanturley/gout
gout is glut for go. 
window creation/keyboard/mouse working amd64 linux/darwin/windows.
AND it knows what goroutines and channels are unlike sdl2/glfw
there is a TODO list in the readme for where I am going with it.
probably some healthy bugs to ;)


Also this
https://groups.google.com/d/topic/golang-dev/P1ATVp1mun0/discussion
http://golang.org/s/go14android
mentioned a possible new/old gl binding closer to gopher central.

I will help with a community gl binding (mine, yours, his whatever), but I like my insanity to much to stop working on mine ;)

[Bryan Turley]

I added a safe, safer, unsafe report to my generator today.
It is interesting.  The information in gl.xml can be used to automatically create safer versions of more than half of the unsafe gl functions.
There may be more ways to improve this.  I didn't know it was over half until I generated this report today.
I am sure there are plenty more bugs in gl.xml to I have just been to busy writing other related things to continue looking.

https://raw.githubusercontent.com/bryanturley/gl/master/gl_safety.txt

I have been slowly sending bug reports to khronos to further this goal as well.
So far they have accepted all the reports.

[Eric Woroshow]

Glow is compatible with glfw. Indeed Glow uses glfw3 for its examples.

Where Glow emulates GLEW is only in attempting to determine which extensions are available. It does so only based on the availability of the necessary function pointers, not based on glGetString(GL_EXTENSIONS) like GLEW. Moreover GLEW determines which OpenGL version is available and Glow forces you to choose at the package level from the start.

On Sunday, July 13, 2014 11:00:56 PM UTC-7, Jrago...@gmail.com wrote:

Is glow compatible with glfw? I know that the glfw headers have to do magic to work with GLEW (and you have to include glew.h before glfw.h to make sure this happens), since, if I'm not mistaken, glow seems to fulfill a similar role to GLEW, I'm curious if there may be conflicts.

[Eric Woroshow]

There are some designs you can implement with the existing version. For example, you are not prevented from initializing multiple OpenGL packages spanning multiple versions. If initialization fails then that particular OpenGL version is not available. You can use your base OpenGL version package for most operations and defer to the higher-version package when making more advanced calls. It's a bit more of a hassle because you need two namespaces but otherwise it should work.

On Sunday, July 13, 2014 11:42:15 PM UTC-7, Jrago...@gmail.com wrote:

 Glow forces you to choose at the package level from the start.

Hmm... this seems like a problem to me. For many production-quality things, it is *very important* to be able to check the version dynamically on the target machine, especially since rather extreme features and optimizations like programmable pipeline tesselation may only be available on a very small percentage of user machines. Is there any way to make supporting multiple targets easier without making the implementation of the generator too complex?

[Eric Woroshow]

> For example, you are not prevented from initializing multiple OpenGL packages spanning multiple versions.

With the caveat that Issue 12 must first be resolved but it should be a straightforward fix. I should get to it within the week, but of course I'm happy to accept pull requests if anybody else wants to get to it sooner.

[Stephen Gutekanst]

Just saw this -- I want to clarify that Dmitri has encouraged me to pursue using go-gl/glfw3 and go-gl/glow instead of my glwrap and native/gl packages.

Article about it here: http://azul3d.org/news/2014/yin-and-yang-using-glow-and-glfw.html

On Friday, August 22, 2014 4:31:52 AM UTC-7, Jrago...@gmail.com wrote:

I found another one:

https://github.com/azul3d/native-gl

This one fulfills a sort of similar role to go-gl/gl, though it does have one primary advantage: optional call batching, which appears to be legitimately and significantly faster. (By call batching I mean that calling an OpenGL function actually adds it to a queue, and then all OpenGL calls are executed at once with a single call to an Execute function).

He also has a windowing system:

https://github.com/azul3d/chippy

Though it doesn't support OS X right now.