GL Error 1282 for glClear and glClearColor with GL Context created in Golang but used in C++ on Windows

[zwang]

I build a demo app trying to use GLFW with Go together (this project) with V8go (https://github.com/rogchap/v8go) on Windows. The idea is to use GLFW to create window and execute JavaScript code to call OpenGL ES functions to draw on the window. The OpenGL ES functions are bound to JavaScript environment via V8go.

Initially, I have the OpenGL ES functions bound in the C++ code using ANGLE (EGL + OpenGL ES 2) (https://github.com/zwang/openglesgowin), but it keeps giving me 1282 error when calling simple function like glClear and glClearColor. I have double checked, the functions should be called in the same thread which makes context current. And in v8go, there is no thread switch either. So this 1282 error is really weird. I am wondering if I missed anything here regarding how GLFW-go works.

Later, I tried binding the GL methods in the Golang code (https://github.com/zwang/openglesgowin/tree/bindGLInGolang) (using https://github.com/go-gl/gl/tree/master/v3.1/gles2), also EGL + OpenGL ES 2), this time the functions like glClear and glClearColor are executed correctly.

I also created a c++ project with the same logic and GL bindings using ANGLE (EGL + OpenGL ES 2) done in C++, and use C glfw for window creation, the GL functions calls returns no error and works correctly too. https://github.com/zwang/helloTriangle

Another thing I noticed here is the Windows build flags by default using opengl32 at here #cgo windows LDFLAGS: -lopengl32 -lgdi32 at https://github.com/go-gl/glfw/blob/master/v3.3/glfw/build.go#L4 . Although I deleted -lopengl32 or replaced it with -legl or -lglesv2 or combinations of these two, does not make any difference.

Please let me know if there is anything I might be missing or doing wrong here. Any help is appreciated. Thanks in advance.

[pwaller]

Apologies that this repository is probably not a great venue to seek help. Nobody is paid to maintain this project so it is using our limited spare time. If I am reading correctly, this "works" for you when you call glClear from Go, in the bindGLInGolang branch? I wonder however if you're actually checking glGetError(), it seems possible that this code is actually failing in the same way but you're not checking the error (just a guess). I've had a look and don't see an immediate explanation. I'd try using an OpenGL debugger to understand why it's returning 1282 (GL_INVALID_OPERATION). If I understand the docs correctly, this should only be the case if glClear is called between glBegin/glEnd, but it seems possible the docs are not complete on this front.

https://docs.microsoft.com/en-us/windows/win32/opengl/glclear

Good luck and feel free to continue commenting on this thread even though I'm closing it, because this does not seem to be an issue with go-gl/glfw, as written. If you can provide a minimal reproducer which shows the issue then by all means please file a new issue or we can reopen this one.

[zwang]

HI @pwaller thanks for checking this our and the reply. I totally understand the nature of Open Source project and everybody is not paid. Please no need for apologies. I appreciate your help.

My case is definitely complex as it involves multiple projects. The reproducible minimal project is at here: https://github.com/zwang/openglesgowin . However definitely it requires multiple setups in front.

Good news is I just figured this whole thing out by myself last night. I am posting here just in case it helps. There are two issues preventing me from using OpenGL ES + EGL across my demo app in both C++ and Golang world.

One is in glfw, the CGO LDFLAG for windows is by default in -lopengl32, which means it by default using desktop OpenGL, and it conflicts with the OpenGL ES used in the C++ side. The fix for this is to either change #cgo windows LDFLAGS: -lopengl32 -lgdi32 to #cgo windows LDFLAGS: -lgdi32 or change to #cgo !gles2,windows LDFLAGS: -lopengl32 -lgdi32 and passing a tag -tags gles2 in the go tool argument. I think the second way is better and it provide more flexibility. I can create a PR for this if we are OK with this.

Another issue is in github.com/go-gl/gl repo. Similar problem. It is by default windows LDFLAGS of -lopengl32 in multiple places. This cause the library buiding with Desktop OpenGL and again conflicting with the ANGLE's OpenGL ES contexts in C++. The fix is similar above too. However, there is some EGL related fix to be made in go-gl/gl since ANGLE is using EGL + OpenGL ES 2.

Hope this helps.

[zwang]

Created this PR: #306