Glow: OpenGL bindings for Go

[Eric Woroshow]

https://github.com/errcw/glow

I'd like to introduce (yet another) set of OpenGL bindings for Go. The features I believe set Glow apart are:

• Bindings that mirror the C specification as closely as possible using native Go types
• Support for multiple OpenGL versions and profiles (core and compatibility)
• Support for extensions

Glow is the first non-trivial piece of software I've authored using Go so I'd love feedback both on the generated bindings plus the generator code.

I'm happy to accept feature requests, bug reports, and pull requests. I'd like for Glow to be useful to the community!

Thanks,

Eric

[Job van der Zwan]

Any particular reason you chose to fork GoGL2?

[Eric Woroshow]

I forked GoGL2 because the author was, at the time at least, not interested in working on it. I had a few pull requests implementing new features that were never merged. Creating a fork gave me the freedom to move quickly.

[Tyler Compton]

It seems to me that the functions found in the "glt" package are always going to be necessary or at least helpful in every Glow program, so why not just have them included in the "gl" package?

[Eric Woroshow]

Originally my thinking was that the glt package would also contain shared Go-C bridge types such as "type Enum uint32" such that multiple GL packages would have compatible types. However I've since revised my approach (I don't believe the additional types provide much, if any, value) so pushing the helper functions into the generated package now makes good sense. I've filed an issue to track the change.

[Eric Woroshow]

I'd like to announce that I've released go-gettable packages, plus I've addressed a few usability issues, so it should be easier than ever to use glow.

The prebuilt packages include support for OpenGL 3.2, 3.3, 4.1, and 4.4 across both the core and compatibility profiles and include all extensions.

e.g., go get github.com/errcw/glow/gl-core/4.1/gl

[Dmitri Shuralyov]

That's really cool, thanks for sharing the update!

What do you think about the possibility of moving glow under the go-gl organization namespace?

[Dmitri Shuralyov]

Eric, I've made a post in the go-gl mailing list, perhaps you could chime in with your thoughts: https://groups.google.com/forum/#!topic/go-gl/732mmTmJTeY.

[Jsor]

I think the Ptr method is potentially dangerous in Go 1.3, since you're not supposed to store Go pointers in uintptrs anymore.

[Dmitri Shuralyov]

Jsor, which repo are you referring to? go-gl/gl one or something else?

I believe there's an issue about this https://github.com/go-gl/gl/issues/156 but I'm not sure what the conclusion is.

[Jsor]

glow/gl-core/3.3/gl/conversions.go

https://github.com/errcw/glow/tree/master/gl-core/3.3/gl

I also note that go vet absolutely freaks out about potential uses of unsafe in the package.go file, but I THINK (don't trust me, ask an actual Go developer) those are fine because I believe the unsafe.Pointers being used originate from querying C for OpenGL function pointers.

[Eric Woroshow]

I filed an issue to track the necessary changes in the glow API. I believe the short answer is that uses of uintptr need to become unsafe.Pointer. The other conversion functions Str and GoStr are safe (I think) given the caveats in the documentation.

[Jsor]

Importing unsafe directly is something I'm not a fan of. This is one point I think go-gl has it right on; outside of a few snafus there are currently issues for, anything that requires a list of things (glUniform4fv etc) takes in an appropriate slice and converts it to unsafe.Pointer on the fly. This is more rigid, but safer. Especially since the Go spec doesn't guarantee structs are aligned or laid out in memory order.

[Jsor]

(Also Dmitri me == Jragonmiris, that's my issue on go-gl/gl too :) )

[Eric Woroshow]

> Importing unsafe directly is something I'm not a fan of.

Agreed, which is why Glow offers the gl.Ptr helper function to convert between pointers, slices, and arrays to the unsafe.Pointer type accepted by the Glow OpenGL API. This conversion is not built into the API because Glow attempts to expose the OpenGL functions as faithfully as it can; higher-level libraries (e.g., go-gl/gl) can then sit on top and provide suitable abstractions.

On Saturday, July 5, 2014 7:22:25 PM UTC-7, Jsor wrote:

[Eric Woroshow]

Glow has joined the go-gl organization so the canonical repository is now https://github.com/go-gl/glow. Glow remains under active development will continue to accrue features and fixes. With Glow's move to broader ownership there is hopefully a stronger guarantee of continued attention and maintenance long into the future.