Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add sanitized prebuilt packages #31

Open
errcw opened this issue Aug 8, 2014 · 4 comments
Open

Add sanitized prebuilt packages #31

errcw opened this issue Aug 8, 2014 · 4 comments

Comments

@errcw
Copy link
Member

errcw commented Aug 8, 2014

Following @bryanturley's lead Glow should consider offering "sanitized" packages with a friendlier API. As a first pass I expect two things. One, including only relevant, high-quality extensions. Two, providing functions that use the OpenGL parameter length information (e.g., transforming gl.BindSamplers(first uint32, count uint32, samplers *uint32) to gl.BindSamplersGlow(first uint, samplers []uint32).

@bryanturley
Copy link

I think you should end them in Go like I do. I was treating them as an automatically generated extension. EXT_automagic_go ;)
It would be nice if current and future go opengl bindings were more compatible with each other.
Also I have found that in many cases you still need the unsafe version of some functions for odd corner cases.

I was about to add uintptr versions of the functions that take unsafe.Pointers but actually want pointer sized offsets. I have not come up with a good suffix for them yet. I have found that I generally use the offset form, so a uintptr would be better.
Most of those functions (depending on current gl state) will accept a real pointer or an offset, which is very annoying.

You may also want to hold off until the gopher overlords figure out the go pointers in c problem as well.
https://code.google.com/p/go/issues/detail?id=8310
Once that gets sorted there may have to be some changes in everyone's gl bindings.

@capnm
Copy link
Contributor

capnm commented Aug 8, 2014

EDIT: stay technical
Another option to look for is to manage the memory on C side and use runtime.SetFinalizer, see:
https://groups.google.com/d/msg/golang-dev/pIuOcqAlvKU/5Lm8fRaGtRoJ

@bryanturley
Copy link

@capnm: Since glow is part of go-gl now, it would probably be best to post this kind of message on the go-gl mailing list instead of in an issue tracker. Don't want to derail another issue thread.

@bryanturley
Copy link

Nevermind about holding off seems a copying/moving GC won't happen till go 1.6 a full year away.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants