I never decided when to freeze the method signatures of the gl package. It definitely should be frozen by the time Go 1.5 comes out. But I suppose it is still safe to change some, as long as nothing breaks silently.

• BufferData change looks good.
• s/Gen/Create/ is OK. Create is a better word.
• I'm not really interested enough in exactly matching WebGL to change Get{Shader,Program}i to Get{Shader,Program}Parameteri. Seems unnecessarily wordy, and the names are clear enough.

If you'd like to send CLs for the first two, please do. Update any call references to them in the mobile repo please.

Okay, sounds good, I'll do that. Would you want this CL separately from adding WebGL or is fine to do everything in one?

Another issue I've noticed in the internal glBoolean helper:

func glBoolean(b bool) C.GLboolean {
    if b {
        return 0
    }
    return 1
}

Its logic seems to return the opposite of what it should. Is that unintentional?

If so, I'll fix that too, and probably use the TRUE and FALSE consts.

Separate please. Any idea that's logically separable should be a separate CL.

I don't know what happened to glBoolean. That looks entirely wrong. Strangely, it's used a bunch, so I don't know how anything works.

I don't know what happened to glBoolean. That looks entirely wrong. Strangely, it's used a bunch, so I don't know how anything works.

Yeah, I was surprised to find that too.

It was causing issues for my existing GL code (that previously worked) when I did gl.VertexAttribPointer and needed to set normalized to true.

@crawshaw, I've submitted a CL at https://go-review.googlesource.com/8000, please take a look.

I've found another inconsistency:

func DrawElements(mode, ty Enum, offset, count int)

That parameter order deviates from both OpenGL ES and WebGL specs:

https://www.khronos.org/opengles/sdk/docs/man3/html/glDrawElements.xhtml

Can we change it to have same parameter order?

func DrawElements(mode Enum, count int, ty Enum, offset int)

Go for it.

Another issue.

Change Request Summary

GetActiveUniform(p Program, u Uniform) -> GetActiveUniform(p Program, index uint)
GetActiveAttrib(p Program, a Attrib) -> GetActiveAttrib(p Program, index uint)

Rationale

Uniforms have concept of a Uniform Location, as well as index. (Something similar, but less clearly defined also applies to attributes.)

The OpenGL ES spec for glGetUniformLocation states the return type is GLint and it represents:

glGetUniformLocation returns an integer that represents the location of a specific uniform variable within a the default uniform block of a program object.

(Emphasis added by me.)

Uniform index type used is similar but not the same, it's GLuint. See, e.g., https://www.khronos.org/opengles/sdk/docs/man3/html/glGetActiveUniform.xhtml.

The WebGL spec defines a named type WebGLUniformLocation to represent Uniform Location, and also uses GLuint for the index.

Consider glGetUniformLocation:

WebGLUniformLocation? getUniformLocation(WebGLProgram? program, DOMString name)

The current equivalent x/mobile/gl API is:

// GetUniformLocation returns the location of uniform variable.
//
// http://www.khronos.org/opengles/sdk/docs/man3/html/glGetUniformLocation.xhtml
func GetUniformLocation(p Program, name string) Uniform

Which is good (although I would've preferred the name UniformLocation rather than deviating from the spec).

But another func expects an index of the uniform, not Uniform Location as its parameter:

WebGLActiveInfo? getActiveAttrib(WebGLProgram? program, GLuint index);
WebGLActiveInfo? getActiveUniform(WebGLProgram? program, GLuint index);

Yet the x/mobile/gl API expects a Uniform Location type instead of an index:

// GetActiveUniform returns details about an active uniform variable.
//
// http://www.khronos.org/opengles/sdk/docs/man3/html/glGetActiveUniform.xhtml
func GetActiveUniform(p Program, u Uniform) (name string, size int, ty Enum)

This makes GetActiveUniform really awkward to use, because there is no way to get/create the Uniform type.

The typical usage of GetActiveUniform makes sense when the parameter, correctly, is an index:

uniformCount := gl.GetProgrami(program, gl.ACTIVE_UNIFORMS)
for index := 0; index < uniformCount; index++ {
    name, size, ty := gl.GetActiveUniform(program, index)
    ...
}

As things are, I need to try to create a Uniform type by doing gl.Uniform{Value: int32(i)}, which is awkward and not cross-platform compatible.

On desktop both Uniform Location and index are internally just integers, so it can be done, but that's going around the type system instead of using it correctly. The problem is that in WebGL, the Uniform Location is actually a JavaScript Object, while uniform index is an integer, so it can't work. See this answer for relevant info.

I highly recommend following the spec and using the type system correctly here. GetActiveUniform and GetActiveAttrib should accept an index as their 2nd parameter, not location type.

Would that change be amenable to you?

Edit: This also applies to EnableVertexAttribArray, DisableVertexAttribArray, and VertexAttribPointer. They take an index, not location type. Edit 2: Actually, the spec is pretty confusing/inconsistent for attrib location/indicies... It seems they're mixed and match and treated the same. :/ Edit 3: After looking more into it, this does not apply to any of those 3, sorry.